It would be very interesting that the codes are applied in the next IRRlicht version if it work. We could do very interesting levels with that and still keep a good framerate. (So IRRlicht will still be a Lightning fast rendering engine )
Yeah, that looks cool, and if I remember correctly it hass been done before, but I could be wrong. It would definitely be cool to have that in the engine.
One thing that I would like to say though is that I won't be implementing it anytime soon. The reason being, I would only write a portal occlusion culler if I were to have an editor that works for setting up the sectors. And right now, I don't feel like doing that.
But hey, christianclavet, that would be cool if you did something with portal occlusion culling.
I really don't know how I could implement that, but I'm still figuring a way to re-code my current editor for Visual C++ Express. I will try to put the code in a more "coherent" way, and with complete includes with headers (last time it was not done properly).
The sectors can't be done proceduraly?
If others could helps we could have this surely faster, but your current code could motivate some to create new components for a future version of IRRlicht.
As for the portal occlusion, check out Lightfeather 3d engine (based on IRRlicht) - they have implemented portals (Electron was one of the developers I guess he's still working as a dev. out there ):
christianclavet wrote:I really don't know how I could implement that, but I'm still figuring a way to re-code my current editor for Visual C++ Express. I will try to put the code in a more "coherent" way, and with complete includes with headers (last time it was not done properly).
The sectors can't be done proceduraly?
If others could helps we could have this surely faster, but your current code could motivate some to create new components for a future version of IRRlicht.
Well if you were to do them procedurally, then your basically just re-creating an octtree, so you wouldn't get certain benefits.
And I can't make the code available, believe me, the state of my code and design right now is quite horrible. I've also run into some problems with the depth buffer. And my crappy build times are a little discouraging as well. It takes about 4 minutes to build it with a change in just the scene manager, and even longer if it's something in the driver pipeline.
Halifax wrote:
The sectors can't be done proceduraly?
Well if you were to do them procedurally, then your basically just re-creating an octtree, so you wouldn't get certain benefits.
Ok. I've checked how they do to create portals methods and your're right. They mostly use and occtree to calculate for the occlusion. The current OCCTREE that we have in IRRlicht are used only for collision (to my current knowledge). Can't the info in the current OCCTREES be used to get the sectors?
What are the benefit of creating this manually in an editor?
Well the thing is that octrees are stop portal generation based on the number of scene nodes. Which means that it may not always be as efficient as hand done portals could be. Plus some excess portals can be added to an octree as well.
At any rate, sorry about the lack of updates on this. I kind of had a big move from PA to FL.
This method could be added to the manual method. So, we could have a tool for testing and have more efficiency (Sometimes the manual method could be better, but how many time you would put on this for gaining 2-3 FPS)
We could use the Octrees for all the scenes and use only the manual method on problems areas (For example when in your scene, your FPS drop dramaticaly and the auto(octree method) wouldn'nt fix the problem.
Keep up the work! This project give us hope that this will be happening someday!
Could you please give us access to up to date sources so that I may try it (on various platforms) and possibly fix/improve it if needed (if within my grasp).
I'm really interested in getting the most out of my hardware and after enabling MMX/SSE/SSE2/SSE3 and forcing GCC to use SSE for all floating point math (speed improvement measured on the current code of TFK engine : up to 3 times faster) the next logical step is to fiddle with GPU features, then I may consider using threading to take advantage of multicore CPUS.
Hey, we might be able to get an Irrlicht-based game to be both visually appealing and lightning fast someday
Well full.metal.coder, Nadro actually beat me to the punch. I have been gone and missing from the community for quite a while. But I have checked his code, and it is basically an exact match to mine. The only difference is that I implemented the actual occlusion culling handling in Irrlicht, instead of leaving it up to the user. Which was stupid, now that I see that in hindsight.
But yeah, anything you could do with my code, you can do with Nadro's.
Halifax wrote:
Ok. I've checked how they do to create portals methods and your're right. They mostly use and occtree to calculate for the occlusion.
What are the benefit of creating this manually in an editor?
Unfortunately no, we have no method for creating portals automatically, it's done by hand. I do it in my game-specific editor (which is sadly unmaintained at the moment as I haven't had much time for game programming lately)
You do a lot of programming? Really? I try to get some in, but the debugging keeps me pretty busy.
)
):