Hi,
probably a silly question, but why are Quake .bsp files loaded as OctreeSceneNodes?
Of course the obvious answer is SPEED, but why? The files are already "optimized"
as BSP ( hence the ending .bsp ) and should be loaded as such.
If octree scene management is such an advantage, then why not switch to octree
in general ( i think Urho3D uses octree only )? Don't answer "there is no one to do
the work" - i know that - but i would like to understand the technical background.
BSP, Octree
Re: BSP, Octree
They aren't? Not in 1.7 nor in today's svn.
edit: If you mean the examples, I guess it made sense when those were made.
edit: If you mean the examples, I guess it made sense when those were made.
Re: BSP, Octree
What do you mean by "switch to octree in general"?
For nodes that are small so you either see it or not (e. g. a character), an octree does not help.
And I think an actual bsp is simply not implemented.
I guess BSPs are faster to render, but are more complicated to precompute, and having BSP rendering code, but none for it's generation is also not good. That's why there's only octrees i think.
For nodes that are small so you either see it or not (e. g. a character), an octree does not help.
And I think an actual bsp is simply not implemented.
I guess BSPs are faster to render, but are more complicated to precompute, and having BSP rendering code, but none for it's generation is also not good. That's why there's only octrees i think.
-
Cube_
- Posts: 1010
- Joined: Mon Oct 24, 2011 10:03 pm
- Location: 0x45 61 72 74 68 2c 20 69 6e 20 74 68 65 20 73 6f 6c 20 73 79 73 74 65 6d
Re: BSP, Octree
the main problem with enabling octrees for bsp maps by default is that they're too dependent on settings - not to mention the user may want to use a different tree acceleration structure, such as a kd-tree (not necessarily better, but someone may want it).
Also consider the case of a machine with a weak cpu but a beefy gpu, on such a setup the program may actually run slower with octrees. (not to mention various edge cases that can slow down a lot with octrees)
there's no setting that is optimal for every map, depending on the map it's even possible to see slowdowns due to them (or at the very least to see no major gain but an increase in memory consumption).
Ideally implementing correct bsp support would be ideal [and pre-computed for the map in question during build] but such is not available in Irrlicht to my knowledge (rather to my understanding it parses the brushes and then builds triangle meshes, I may be wrong on his).
As for enabling octree on any node - that'd be a terrible idea, you'd increase code complexity and memory usage for comparatively small gain for most nodes (for example so small that it's more efficiently depth-culled and frustum culled)
Also consider the case of a machine with a weak cpu but a beefy gpu, on such a setup the program may actually run slower with octrees. (not to mention various edge cases that can slow down a lot with octrees)
there's no setting that is optimal for every map, depending on the map it's even possible to see slowdowns due to them (or at the very least to see no major gain but an increase in memory consumption).
Ideally implementing correct bsp support would be ideal [and pre-computed for the map in question during build] but such is not available in Irrlicht to my knowledge (rather to my understanding it parses the brushes and then builds triangle meshes, I may be wrong on his).
As for enabling octree on any node - that'd be a terrible idea, you'd increase code complexity and memory usage for comparatively small gain for most nodes (for example so small that it's more efficiently depth-culled and frustum culled)
"this is not the bottleneck you are looking for"
Re: BSP, Octree
I only asked because i saw that Urho3D uses Octree as fefault and with Ogre you can choose the method, see
http://www.ogre3d.org/tikiwiki/SceneManagersFAQ
So you say Irrlicht has the easiest to use and most "generic" solution?
http://www.ogre3d.org/tikiwiki/SceneManagersFAQ
So you say Irrlicht has the easiest to use and most "generic" solution?
Re: BSP, Octree
aaammmsterdddam is right.
With Octrees it is a question of finding the right balance between Polygons per Node and Node Count.
There is no real hard and fast mathematical method to determine this. Its trial and error here. (Like UV Unwrapping)
The problem is that different levels have different polygon counts which means that
each level will probably want its own set of parameters i.e. Polys per node which generates
a unique Node count. Polys per Node versus Node count (those boxes also used with Voxelising Objects)
Now, with Binary Space Partitioning (BSP) it gets a LOT more complicated.
I speak under correction but to me it looks like when a BSP is created,
The BSP creation Software (Radiant etc) literally "walks" through your
level and fires rays all over the place to ultimately determine "What IS DRAWN and what is NOT DRAWN at which CAMERA POSITION".
Now, once the BSP tree has been created it saves your level in a "node-tree" type fashion.
How this is done, I wish I knew and there is another problem.
This BSP now has to be loaded by your engine which in turn needs to understand and implement
the same logics used by the external BSP creation Software.
Irrlicht, as far as I know has no such BSP interpreting facility, BUT..
Octrees gets far too little attention because they are easily misunderstood.
The Octree system keeps dividing your level up into smaller and smaller Cubes (or Cube-like) areas until a
given threshold is reached i.e. Polys Per Cube. (not necessary perfect cubes but you get the picture)
which is checked, in real-time if they fall into the View Frustum or not.
Now the system only renders the polys inside of those "cubes" that are inside of the Frustum.
Lots of time saved.
BUT.. There may be cubes containing hundreds of polys which cannot be seen by the camera but
is still rendered because they fall into the View Frustum.
Enter the BSP..
The meaning of BSP does not necessarily mean "only one way" to do this but means
"All the methods that could possibly be used to accomplish the hiding (not rendering) of invisible parts".
I had a look at some of the methods used, but alas have found no way to do this in Irrlicht Yet.
I am considering a "Trigger System" which simply sees where the camera is and then decides according
to this position what is visible and what is not.
The "Automatic Firing of Rays" (Radiant at BSP Compilation) I have to do myself as I fly through my level
and decide where the "Trigger Cube" would be for which parts of the level.
Very primitive but does the trick. Having a external BSP Creator and a BSP interpreter in our engine is what we want.
So given the Camera Position, the BSP system then knows what is visible to the player and what is not.
I've been playing around a lot with ID Tech 3 (Quake 3) "*.bsp"; "*.pk3" etc, material and trying (still unsuccessfully)
to get Normal Maps working with them. There are TONS of material available on Quake 3 BSP's using Blender and Radiant etc..
I might post some screenshots just to liven up this discussion.
With Octrees it is a question of finding the right balance between Polygons per Node and Node Count.
There is no real hard and fast mathematical method to determine this. Its trial and error here. (Like UV Unwrapping)
The problem is that different levels have different polygon counts which means that
each level will probably want its own set of parameters i.e. Polys per node which generates
a unique Node count. Polys per Node versus Node count (those boxes also used with Voxelising Objects)
Now, with Binary Space Partitioning (BSP) it gets a LOT more complicated.
I speak under correction but to me it looks like when a BSP is created,
The BSP creation Software (Radiant etc) literally "walks" through your
level and fires rays all over the place to ultimately determine "What IS DRAWN and what is NOT DRAWN at which CAMERA POSITION".
Now, once the BSP tree has been created it saves your level in a "node-tree" type fashion.
How this is done, I wish I knew and there is another problem.
This BSP now has to be loaded by your engine which in turn needs to understand and implement
the same logics used by the external BSP creation Software.
Irrlicht, as far as I know has no such BSP interpreting facility, BUT..
Octrees gets far too little attention because they are easily misunderstood.
The Octree system keeps dividing your level up into smaller and smaller Cubes (or Cube-like) areas until a
given threshold is reached i.e. Polys Per Cube. (not necessary perfect cubes but you get the picture)
which is checked, in real-time if they fall into the View Frustum or not.
Now the system only renders the polys inside of those "cubes" that are inside of the Frustum.
Lots of time saved.
BUT.. There may be cubes containing hundreds of polys which cannot be seen by the camera but
is still rendered because they fall into the View Frustum.
Enter the BSP..
The meaning of BSP does not necessarily mean "only one way" to do this but means
"All the methods that could possibly be used to accomplish the hiding (not rendering) of invisible parts".
I had a look at some of the methods used, but alas have found no way to do this in Irrlicht Yet.
I am considering a "Trigger System" which simply sees where the camera is and then decides according
to this position what is visible and what is not.
The "Automatic Firing of Rays" (Radiant at BSP Compilation) I have to do myself as I fly through my level
and decide where the "Trigger Cube" would be for which parts of the level.
Very primitive but does the trick. Having a external BSP Creator and a BSP interpreter in our engine is what we want.
So given the Camera Position, the BSP system then knows what is visible to the player and what is not.
I've been playing around a lot with ID Tech 3 (Quake 3) "*.bsp"; "*.pk3" etc, material and trying (still unsuccessfully)
to get Normal Maps working with them. There are TONS of material available on Quake 3 BSP's using Blender and Radiant etc..
I might post some screenshots just to liven up this discussion.
Re: BSP, Octree
X-Labs from Return to Castle Wolfenstein..
Irrlicht can handle these but Copper Cube can't ??
Irrlicht can handle these but Copper Cube can't ??
