7 replies to this topic

[ely_bob]

SO in a typical(at least what I've found) terrain the terrain is generated from a height map and then doodads are added(trees fences etc.) fine.

I want a bridge.

that said would it now be easier to export my heightmap generated terrain into blender and then extrude a bridge and import it.. or make a "location" that is of type BRIDGE and then modify positions "on the fly" as it were...?


related question, that i can find absolutely no reference to.. if I do make my entire world out of meshes bridges rocks etc. what is the best and I mean fastest in the run time frame (not development frame) way to keep track of all of it, acurately.

[Reedbeta]

Why would you try to "modify positions on the fly" for a static object like a bridge? You can certainly model it and render it on top of the terrain like anything else.

As for your second question, google for "scene graph", "aabb tree" and "octree". These should get you some good reading.

[ely_bob]

Well I intend to use a kb-tree/quasi BVH... But I'm still fuzzy about exactly what will happen at the bifurcation point (and yes I know there will be a volume value, but I should like to implement a method that is stable as the Limit of the bounding volume goes to Zero(+).

But unfortunately my coding machine is in the shop right now so I am simply doing some planning.

See if I'm thinking about this right:

you have one surface (in one leaf of your tree) upon which the cross-sections in the Z axis are {|,\,Y,\,|} and in the X axis,{ {_,-},-,_}, or in the X showing volume { {_,-u},-,_}.

Naively, one could use a Height Map approach, however this would result in always being on top of the bridge. -Wrong. Or we could recognize that when the character walks onto the (bridge_0 access area) that they are "on the bridge", and add a bridge value to the returned height map value, which would be WAY quicker, then doing a local kd-search, (also would require embedding the bridge value into an R,G,or B channel of the height map, and limit you to at most floor, +3 bridges (in one Y3 axis). which would work (well enough) if the levels are designed "reasonably". --- at least that was my first thought on the subject. however this would make it hard/Impossible to do things like railing. (that is what I meant by "modify on the fly" )

You could repartition the graph so that the bridge surface is in one box, and the terrain is in another, but this would REQUIRE manual editing of ALL the partitions in the scene graph, resulting most likely in poorly optimized bounding volumes(this would cause various bounding volume slivers/ or irregular volumes hear and there) (think 3D bridges of Hanoi, in the Grand Canyon += 6 rotations ), not to mention the bridges that aren't nicely aligned to the internal coords. anyone like diagonal bridges...


I'm probably going to do it with a hybrid of the two methods,... but I'm just curious if I'm still missing anything. because that seems to happen enough that when I start to tinker with something that works(well) I really want to know what it is that I'm about to attempt to do...

[Reedbeta]

First of all, I have no idea what you mean when you talk about the "bifurcation point" or why you would want to take the limit as the bounding volume goes to zero...nor can I make any sense of the notation like {|,\,Y,\,|} and so on.

But, generally, adding additional objects into your scene graph shouldn't require manual editing of anything, and I'm confused as to why you think so. When you build your kd-tree or what-have-you, it should take the locations of bridges and so forth into account at the same time as the terrain.

Alternatively, for collision detection purposes you might keep the heightfield out of the kd-tree entirely and treat its collisions specially.

[ely_bob]

Slices... of the mesh.

...Bifurcation point is the place at which one becomes two, common bifurcations : a Y in the Road, 0+, 0-, 0 in floats (actually a trifurcation), or if you have two meshes with verts A,B,C,D E,F and A',B',C',D', E, F with C=C', D=D' As you would if you kept the ground under the bridge walkway.

I think the reason I sound confused is because my terminology is ... not ideal...

I want the collision, navigation, and physics engine to be essentially tied into one compact framework, so that you can check the point without having to check it's occurrence inside a bounding volume (from the tree)...

i.e. I need a way to QUICKLY test any trivial point (without needing a frame rotation (for instanced objects), or doing multiple Box checks, I have a very fast, bounded, approach, that takes my version of a Nav mesh, can accommodate the AI movements I want/don't want without introducing the World/local error issue, and (I haven't counted exactly.. but) can do all the collision checks for a projectile in at most 5 operations. so I like it so far... =)

But I think you've shown me the answer... although I don't yet know how to restate it back...

--I don't think what I built could really be called a kd tree in retrospect...

Sorry tired. and hungry.. if I come to a coherent realization of what just happened here I make a post later (tomorrow) otherwise thank you sir for your time, believe it or not you were helpful.

[ely_bob]

Reedbeta said:

Why would you try to "modify positions on the fly" for a static object like a bridge? You can certainly model it and render it on top of the terrain like anything else.

As for your second question, google for "scene graph", "aabb tree" and "octree". These should get you some good reading.

O.k. this "Scene Graph" you talk of is where we are having a disconnect..
I suspect you are talking Drawable Graph of the on screen scene..?

I'm talking in terms of a Graph of navagable, physical space (including, collision tests, Nav calculations, physical constraints, Nav meshes, internalized coords.. etc).
the Space Graph allows for the Drawable graph as a leaf. I.e.
you never "really" need to do a frustrum test because it is ...
I guess ... ~precalculated~ maybe...(Actually it is folded into the space itself..
but that is not a CS term really, it is more of a particle physics approach...)

As for the subject of this thread, I need to use a "Gravity Mesh" (negative gravity)
at the "Top" of the level, this will simply force everything away from it..
solving the problem.. not elegent but very functional in principal.


I optimize away (loose) certain accuracies like a radial test (i can still do it but it would be slow in ths space),
but I replace it with a fast regular polygon (say Dodecahedron) and it is back...

but really a dodecahedron and a sphere are not that dissimilar....

yes my Content will be "LARGE-ER" but it will really free up compute cycles.

[alphadog]

ely_bob said:

I want the collision, navigation, and physics engine to be essentially tied into one compact framework

Not understanding much of what you are trying to say. Too many tangents and weird lingo. But, if I have to hazard a guess, I'd say this line above may point at the root cause of all your problems. It has a "smell", in programmer's parlance. You are perhaps trying to put too much divergent/orthogonal concerns in too little a code space. It's always a recipe for disaster...

[ely_bob]

it's o.k. I solved the problem....

and like I said it is the folding of the space(makeing things orthagional into an alternative basis..i.e coliniear, until the problem is in a sufficiently small dimensionallity space... done., )

my issue was in my limited exposure to heightmap style map levels, and had not seen a reference for model style maps... but I got serious for a couple of days and worked out all the kinks.. and it still works out to be darn fast.