BSP, Octree

[Vectrotek]

Someone's kitchen.

[Vectrotek]

I'm trying to get Normal Maps working with these, but the old "2TCoords" thing is in the way..
I need 2TCoords AND "Tangents and Binormals"..
I can't figure out how to do it even if I can use the Vertex Colours as a vehicle for the SECOND SET OF UV's..
"*.irrmesh" is cool for doing 2TCoords and Tangents but how are the materials for these "Quake3 Objects" manipulated
to handle our Shadows and Light Maps in our GLS and HLSL Shaders ?
How is the UV coords of these extracted and then Packed and Unpacked for Shader Use?
How do we extract the "Lightmaps" (somehow hardcoded into the BSPs).
I know we are using Octree to render a BSP which is cool.
Anyone played around with this?

[Vectrotek]

The "OCTREE" at work..

[Vectrotek]

If you want to see more on the Internal Workings of Octrees
then try "Digiben"'s Open GL tutorials on the net..
Irrlicht does a fine job though and you don't even have to
code your own Octree Generator.

Here are some shots of me trying Digiben's tutorials..
I actually worked painstakingly through this before I realized
that Irrlicht allready has it!

The hand..

[Vectrotek]

Octrees work well with "sparsely spaced" polygions.

[Vectrotek]

Octrees in Irrlicht bumped up the frame rate quite significantly for this "cave". (metaballs in Blender)

[Vectrotek]

The animation needs work but the frame-rate is cool with Octrees.
The character has Normal Maps, but I cant get them onto Q3 Level walls!
I can get Normal Maps with (2TCoords via Vertcol) on "*.irrmesh" but not "*.BSP"

[Cube_]

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.

This is technically correct but not completely correct, there's a billion and one ways to build a bsp tree(binary space partitioning, it's effectively just a binary node tree) but the resulting tree will be more or less identical no matter what method was used, additionally there are different ways of parsing them.

However the main problem is the contents of the tree, a bsp doesn't have to contain brushes per se [bsp maps do, usually - but that's due to format standardization and whatnot]

The problem with parsing it correctly, and presumably the reason irrlicht does not do this, is that you have to fully support all the nodes the map was built for - or at least handle them in some way, irrlicht can read the brush data and turn it into mesh data and it can handle some additional nodes - but it's bsp support isn't complete enough to correctly parse anything but nontrivial examples (moving parts don't work and a lot of maps depend on such).

Well, in any case - I'll stop my nitpicking and let you resume the torrent of screenshots.

[Vectrotek]

[Vectrotek]

Yes. I see now that the resulting tree is the same thing throughout. Thanks.
Now, who is going to cook us up a fully functional Radiant based BSP Renderer / Interpreter
that we can render all ID Tech 3 based game levels just for fun?
Would be nice to have in Irrlicht.

[Cube_]

Yes. I see now that the resulting tree is the same thing throughout. Thanks.
Now, who is going to cook us up a fully functional Radiant based BSP Renderer / Interpreter
that we can render all ID Tech 3 based game levels just for fun?
Would be nice to have in Irrlicht.

I've been thinking of hacking at one for a bit, although not as an irrlicht module - I prefer more broadly reusable code.

[Vectrotek]

Mmm.. Perhaps a complete piece of code in a working example which users could, if they like convert
to a "*.dll" and "*.lib".
Maybe when the thing really works well for existing generators like Radiant etc we could
even work it into a future release?
Could be a nice little pet project!
I'm reading up on it as I get time, but you've probably got more background on this.