| Horde3D http://www.horde3d.org/forums/ |
|
| Optimizing Level Rendering with a BSP, Quad, or Octree http://www.horde3d.org/forums/viewtopic.php?f=1&t=1071 |
Page 1 of 1 |
| Author: | Orm [ 14.01.2010, 13:32 ] |
| Post subject: | Optimizing Level Rendering with a BSP, Quad, or Octree |
This is something that has crossed my mind a few times while I was developing my engine around H3D, and I have come across a snag. I want level geometry to be modeled in a modeling tool like 3DS Max, and distributed in Hordes native format. I understand the algorithms behind generating these datastructures. But I know that in order to actually render such geometry at a playable level and implement things like AI pathfinding (a la A*, I will probably use Bullets bounding volumes for this one to be generated alongside Hordes graph), some sort of spatial scenegraph has to be generated using the given mesh data. I have looked at the terrain extension, but that works off of height maps and works wonders for large landscapes, but not as well for what I have planned. I am going to continue studying the API for some sort of solution, but what is youralls input on this type of problem? As for when the tree would be generated, I was thinking either at load time or generate the structure with an external tool and store the results in XML. Who knows, I may decide to release what I make as an extension. By the way, if I am overthinking this and Horde already handles this for me, tell me otherwise this is going to drive me nuts. |
|
| Author: | Volker [ 14.01.2010, 14:03 ] |
| Post subject: | Re: Optimizing Level Rendering with a BSP, Quad, or Octree |
Did you see the posts of zoombapub? http://horde3d.org/forums/viewtopic.php?f=4&t=930 Maybe that helps you concerning your pathfinding problems. |
|
| Author: | Orm [ 14.01.2010, 14:53 ] |
| Post subject: | Re: Optimizing Level Rendering with a BSP, Quad, or Octree |
That is quite possibly one of the sexiest libraries I have ever seen. (next to Horde3D of course) However, that does not solve my problem as far as level rendering in Horde is concerned. What I don't understand is why isn't there a set of functions that let you obtain data about a specific node, such as the geometry, vertices, indices, texture data, etc... Anyway, thanks for linking me to that. No doubt I will find that to be of use, but problems still remain. |
|
| Author: | Volker [ 14.01.2010, 15:45 ] |
| Post subject: | Re: Optimizing Level Rendering with a BSP, Quad, or Octree |
Orm wrote: What I don't understand is why isn't there a set of functions that let you obtain data about a specific node, such as the geometry, vertices, indices, texture data, etc... h3dMapResStream gives you access to the triangle index data, vertex position data, tangent frame data and static attribute data. Index, Vertex count etc, can be retrieved using getResParamI. Do you missing something specific? |
|
| Author: | Orm [ 14.01.2010, 15:56 ] |
| Post subject: | Re: Optimizing Level Rendering with a BSP, Quad, or Octree |
No, not really. That pretty much covers it.  All I need to do is figure out a way to apply the algorithm and insert the broken up level data into separate H3D nodes. That's where the Bullet bounding volumes might come in handy... or I could roll my own. I don't know. Now I need to figure out how to use the streams.
|
|
| Author: | DarkAngel [ 14.01.2010, 23:29 ] |
| Post subject: | Re: Optimizing Level Rendering with a BSP, Quad, or Octree |
At work (not using Horde3D) we use 3DS max to render different rooms as different models, then in our level editor we place down each room separately. On my "race of death" (Horde3D demo), I used horde's group nodes to group together all the models that made up each "room" (section of the race track). I then use a PVS system to enable/disable these group nodes depending on where the camera is (only enable visible sections of track). |
|
| Author: | zoombapup [ 07.02.2010, 11:09 ] |
| Post subject: | Re: Optimizing Level Rendering with a BSP, Quad, or Octree |
In general, you dont want to tie your navigation representation into your visual scene. In fact, you might well have a visual scene, a physics scene and an AI scene for the same level. The Physics scene is a physics engine representation of the visual geometry, simplified a lot to allow faster collision checks. Often you then process the physics scene to create the AI scene (the logic being that the physics scene is what you can actually walk on, so using that for navigation is correct). Right now in my engine I'm using recast to take the visual scene and voxelize it and turn it into the AI scene directly, which isnt efficient but given my test scenes its ok. I'd recommend working out the physics scene first. Make a world that you can "walk" around with your player character properly and then once you have that, work on making the AI work on the physics data. The main thing is to forget the visual scene, because it really isnt used beyond rendering. Of course you can do some coarse culling to get rid of some of the drawing if you hit framerate issues, but I'd concentrate on the other scenes first. |
|
| Page 1 of 1 | All times are UTC + 1 hour |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|