# sBibi

Member

521

241 Neutral

• Rank
1. ## Black Holes

Quote:Could a clump of mass the size of the earth or the moon become a black hole? no, they aren't massive enough to collapse under their own gravity into a blackhole. but theorically, with enough energy, any lump of matter could be forced into a blackhole... except that, like with the tiny artificial "blackholes", they won't be stable, and as soon as you stop artificially holding them together (assuming you can do so in the first place), they will just blow apart... (though I might be wrong here...) Quote:What would you need to know to calculate a black hole's gravitational force? Probably mass, right? er... yes... like with any other body... Quote:Can you calculate mass from size of event horizon? you have the answer to this in the 7th post: "sr = 2.0 * G * mass / (c * c);" and you have the answers to the rest in the page dv linked: http://www.photon.at/~werner/bh/gvsim.html
2. ## Black Holes

ah, nice.. thanks, I'll google on that =)
3. ## Black Holes

mh, something else: about the singularity thing, I'm not sure a blackhole necessarily means a singularity. if you take a neutron star, what stops if from collapsing further is the strong nuclear force repelling neutrons from one another (which gives a density around 1.10^18 Kg/m^3 if I'm not mistaken), and even then, when the star's mass becomes large enough that the neutron-repelling force can't stop it from collapsing, it collapses again to a quark star... (it seems "logical" (although here, what seems logic might lead to very wrong deductions, of course))... so, why systematically throw in a singularity? why couldn't there be blackholes with quark stars inside? (and how can we know there isn't yet another collapsing level below that?) if any one could answer, or has any links answering these questions, or explaining why not, I'd be very interested! thanks :) EDIT: perhaps it has something to do with the fact that neutron stars can have quark cores, and that a full quark star would necessarily have a core collapsed one or more levels further, and that it is assumed there are no further steps, and no sub-particles below quarks, so the whole thing actually collapses to a singularity? Oo EDIT2: Quote:btw, on a gravitational point of view, a blackhole behaves exactly the same way as a regular celestial body (like a star) would. and the "stretching" thing, is the same as sattellite-ripping tidal effects close to giant planets, so as long as you perform these computations correctly for other massive bodies, there is no specific code to add for blackholes. to give a more concrete example: if you consider the earth, and the sun, and you make the earth orbit so close to the sun that it almost touches it, the earth, although totally roasted, will stay together. if you want it to actually be ripped apart by tidal forces, you'll have to move it to an orbit that's actually below the sun's surface (so that's not possible), however, if the sun had a smaller radius, you could experience such effects... it's the same with blackholes. as they have a smaller radius, orbiting objects can be tidally disrupted much more often, as they may come closer. [Edited by - sBibi on October 31, 2006 12:58:41 AM]

5. ## modelling a Dodekaeder ?

"dodekaeder" seems to be the german word for dodecahedron ? if that's the case, and unless I misunderstood your post, the left image isn't based from a dodecahedron. It's a subdivided icosahedron. (you could rebuild it starting from a dodecahedron, but it would be much more painful than subdividing an icosahedron). and the faces aren't all exactly the same. they seem to be, but there are small differences/distortions. the icosahedron is actually the largest structure you can create in 3D that's made of identical equilateral triangles. (and that's 20 triangles) you can grab an icosahedron's coordinates from paul bourke's platonic solids page you can then subdivide it to get the left image (that would actually be subdivided twice with the algorithm below), with something more or less like: while (subdivisions--) { for (f = 0; each triangle in the mesh; f++) { // grab original face's vertices v0 = cur_mesh.faces[f].vertex[0]; v1 = cur_mesh.faces[f].vertex[1]; v2 = cur_mesh.faces[f].vertex[2]; // compute edge midpoints m0 = (v0 + v1) * 0.5f; m1 = (v1 + v2) * 0.5f; m2 = (v2 + v0) * 0.5f; // // v0 m0 v1 // x----x----x // \ / \ / // \/___\/ // m2 \ / m1 // \ / // " // v2 // build new triangles new_mesh.add_face(v0, m0, m2); new_mesh.add_face(m2, m0, m1); new_mesh.add_face(m1, m0, v1); new_mesh.add_face(m1, v2, m2); } // final step, push back the vertex on the sphere's surface for (each output vertex) vertex = normalise(vertex) * sphere_radius; swap(cur_mesh, old_mesh); } there are many ways to subdivide this, that's probably one of the most straightforward ones, but clearly not the fastest. you could also directly subdivide in one go without iterating, and not be limited to multiple of two subdivision counts (as with the above algorithm), although it would be a little bit more complex, as you would have to take the sphere's curvature into account to avoid distortions when projecting vertices back onto the sphere surface, you also can stripify quite efficiently the output triangles if you wish, the subdivided structure being quite tristrips-friendly, etc... [Edited by - sBibi on November 27, 2005 2:04:34 AM]
6. ## Vertex Meltdown

if you are interested in knowing what maximum precision your floats will have at a certain distance, there is a very easy way to do it... something more or less like: float get_precision(float val) { int prev_val; prev_val = *((int*)&val) - 1; // -1 instead of +1 because you won't go past val anyway, so the actual maximum error you will ever get is the delta between val-1 and val return (val - *((float*)&prev_val)); } (this code doesn't handle values <= 0.0f, denormals, infinities, etc.. but you don't really need to, and it's just a few simples checks to add anyway if you do need it). it just takes advantage of the fact that, if you take a binary representation of a float, let's call it bin_float, bin_float + 1 will be the next representable float, and bin_float - 1 the previous one. just feed the function with the maximum extent you will ever have in one of your world's partitions, and it will give you the maximum error you will get in this space. (or you can also see this as the maximum resolution of a discrete coordinates grid, you can observe that pretty well in your screenshots, see how the vertices are placed on discrete layers on the Y axis, (not the others of course, as only the Y coordinate went very high), getting further apart as the coordinate grows bigger...) if you plan on partitioning the world in.. say... 2000.0f units sized cubes, and each cube's origin is centered, each coordinate will range from -1000 to 1000. so call the function with 1000, and that's it =) EDIT: typo
7. ## Rolling demo of my terrain engine...

appears to run fine here too. ran at an average of 78 fps. GF7800 GTX + 256Mb vram with 78.01 drivers P4 3.4GHz & 2048Mb ddr2

9. ## Is it possible to calculate the volume for a mesh?

Quote:if it's for a game, you'd be better of to make it up. Then you can tweak the gameplay as you wish (add more mass since the ship is more powerful than expected, ect...). I second that.. and a ship's density isn't constant, you could have a very small ship that weights the same or more than a larger ship, how do you determine the average density? the same for all ships? quite restrictive... :/ by hand? then you'd better just set their weight by hand in the first place, and then you won't need their density... anyway.. that's just my opinion.. if you still want to compute their volume, you can use the method Dmytry described in the other thread. (link's somewhere up on this page) I use that method too and it works fine. just take the AABB height and lower Y bound, place the virtual projection plane at min.y - (height * 0.1) (the relative offset is here just to avoid some imprecisions if the meshes you want to measure vary widely in size, then just ignore the Y coordinate of the triangles, compute the 2D area (dot product), and do area * (v0->y + v1->y + v2->y) / 3.0f, and add these values for each triangle to an accumulator. in the end, you'll get the volume. he gave some visual explanations in the other thread if I recall correctly... might be clearer :) note that if your mesh isn't closed, you will have volume "leaking" in or out, depending if the "hole" is located on the top or bottom of the mesh... anyway, make sure the mesh is completely closed.
10. ## Triangle strips for absolutely no USE

yes, this is handy to remove degenerate tris on cards that support it, however, you can exclude all ATI cards AFAIK (except if they implemented this NV extensions in their latest stuff, but I highly doubt it ;)) (although this isn't really a problem is you rebuild the strips at runtime according the the primitive restart extension...) and for dynamic data, unless perhaps on PCIE, I guess the gains from lower upload times due tu less vertices in tristrips would be quite advantageous compared to potential rendering gains with tris... (and if both tristrips and tris were ordered cache friendly, perfs are pretty much the same anyway, (didn't do extensive tests on this though.. the only difference except increased upload rates for tri lists (and it doesn't count if already in vid mem) would be the cost of evaluating degenerate tris, or restart indices (I have no idea of what this costs), so deciding on which one to use depends pretty much on the mesh, and on the usage (dynamic, static..)))
11. ## True interactive storytelling

Quote:Very interactive storyline is Half Life 2. There are no cutscenes and you basically can choose to follow or not follow the storyline. ?? I guess this was ironic :) HL2 is an example of a game _completely_ linear, where you have no freedom at all (except freedom of movement), everything is scripted, and you can fool these scripts quite easily using some tricks like flying, bunnyhopping and grav-jumping... even if you are free to move wherever you want, the storyling is completely static and predefined, you can't do anything else but follow it (or die), you can't even kill these damn "friendly" NPCs that get in your legs all the time and sometimes get you killed because they're so dumb that they block you in some corner and you basically can't move... this is an example of a game as linear as it could be. you have absolutely no choice in the story, it always starts the same, continue the same, and ends the same, as long as you finish the game, no matter how you played...
12. ## Collision Detection with Skinned Mesh

Quote:If you absolutely need per-vertex collision detection, you could always skin the mesh in software. Then, do your tests, and render with the vertices that you already skinned. However, I don't really recommend this, because it is quite slow. actually, to solve this I use collision meshes for nearby LODs, and simple OBB // ellipsoids for further away collision lods. you very probably don't _need_ a per-triangle accurate collision detection on the rendered mesh, and collision meshes are almost always totally sufficient. (they are just very low res versions of the model that enclose the high resolution mesh) you just need to skin the collision mesh in software (you can get away with only 1 weight per vertex, or maybe two or three for a high resolution collision mesh), and software skinning with 1//2 weights is pretty dammn fast (you can use SSE to speed things up even more...)
13. ## Glow/bloom effect

Quote:I think what Sages meant was to render your scene with color writes disabled but not with black. This means your z buffer is written as it should but you save a lot of bandwidth(half?). So: you don't even need to re-render your scene, just render the normal scene, grab the z-buffer, and render the glowing geometry using the z-buffer from the rendered scene. that's all, no need to re-render non glowing geometry...
14. ## Bloodline system for a MMORPG

AP> you've got a very valid point here... just need to look at the female dark elf ratio (and their lightweight clothes) in lineage to be convinced ;)