Depth shadows, Hardware instancing in the OGRE(from NeoAxis)

[betauser]

Hi OGRE Community,

I just want inform about implemented next features in the NeoAxis Engine:
- Hardware geometry instancing
- Depth textures, shadows (ATI, nVidia)
- nVidia hardware shadows
- Fetch4

You can download modified OGRE sources and use code as example for implementation these features in your projects.
Download here:
http://www.neoaxisgroup.com/neoaxis/downloads

To sinbad: I not understand a bit, why you don't like to have depth textures in the Direct3D9 renderer.
Yes, this is hack...but all world use it.
I think this is just Direct3D _API fail_, but these depth textures is a good feature.
We can have better performance by using nVidia hardware shadows and fetch4. (~4 times better shadow quality with same performance).
Also implemented "alpha to coverage" is implemented in the OGRE via hack too. hehe

About hardware geometry instancing. This is harder for implementation, because Direct3D and OpenGL instancing is different a bit.
But i think good idea to implement hardware instancing too. I think possible to make common interface for instancing in the OGRE.
I have implemented instancing in the Direct3D and this is works good.

PS: Btw, code of our modified OGRE sources is not ideal. Looks like as injection , but i think this is not hard to learn.

[sinbad]

Hey, awesome. The reason we didn't originally include depth textures was that they were only supported in GL universally, and needed a hack in D3D9 which originally only worked on nvidia. Since then ATI have actually implemented the hack too so this was back on my agenda.

However, to adopt this for future versions we'd a contributor agreement from you. It would be preferable to have patches too rather than just a snapshot. For both, please see our patch submission page. If you can't do a patch we can try to extract it from your snapshot (please say what base OGRE version you used), but the contributor agreement is definitely needed.

Thanks!

[sparkprime]

Is this depth textures stuff going to give support for hardware PCF? Or just a cheaper individual depth test?

[betauser]

Is this depth textures stuff going to give support for hardware PCF?

Yes.

[havokentity]

Wow nice, will this be added to Ogre 1.7?

[buonnguqua]

Very nice feature
Need add to 1.7 soon as posible

[sinbad]

No new features ever get added to a stable version guys. Provided I get a contributor agreement and a patch, this could go into 1.8 (but I have neither yet).

[sparkprime]

I also am looking out for this... If you get the contributor agreement someone else could make the patch.

[sinbad]

I've chased it up on email but nothing yet.

[betauser]

I will read, sign and send contributor agreement to Sinbad in 2 days.

---

But i cannot make patchs or something like this. Sorry.
In total, our modified OGRE sources is not ideal. A lot of various changes.
I think is hard to make patch.
I think good idea use our modifications as reference and copy/paste.

Also i don't have alot of time to work as contributor with all workaround.
I hope people will understand.

[sparkprime]

The problem is if we just have your modified ogre source then there are 300k lines of code to sort through to work out what changes need to be integrated. Can you at least give the ogre version you started from so we can check for differences there. Even if some of those differences are not related to these things, it would cut down the workload substantially. Having looked at the code there is the 1.6.3 version code in there, but there seem to be a lot of differences still... Is that the right version?

Thanks for your work though, I am looking forward to this.

[sparkprime]

I think this is the right version actually, but there are substantial changes to thread an Ogre::Root object throughout the whole API instead of using a global singleton. There is also a lot of code that is commented out, and a splattering of random minor changes all over the place.

[jacmoe]

The question is: can we complain about it?
At least we are told that it's in there somewhere.

[sinbad]

Thanks betauser (just got your email after my last post).

No, we can't complain - ideally it would be in a form that was easily mergeable, but if not, we'll just have to see whether it's practical to use. It may be that it's easier just to look for the functionality in question and re-implement it using the code as a reference rather than using a direct patch as we would normally wish for. It will still hopefully be quicker than implementing from scratch.

[boyamer]

Take note that NeoAxis uses Z as up axis not Y,so pay attention on this.

[sinbad]

Contributor license received, thanks betauser.

Any assistance with extracting the useful bits and incorporating them in 1.8 will be gratefully received.

[betauser]

Btw, also soon (3-7 days) we will add 3Dc texture support, with automatic converting to RGBA, if format is not supported by videocard.
Both render systems will be supported (Direct3D and OpenGL).

[sparkprime]

You are my hero!

[cyrfer]

Hi,
I just discovered that the Sample_Instancing does not use hardware instancing. I feel lucky that someone has already started this. I was about to give it a go myself in the OpenGL RenderSystem until I saw this thread.

What is the timeline for integrating the instancing support? It looks the fundamental change needed would be to pass the instance count into the render system's ::_render(op) function, then expose a way to control this count in a higher level class (part of Entity?). Maybe the instance count should be part of the RenderOperation structure?

[Edit] I took a stab at it anyway, sync-ing with Hg today. I have a proof of concept working (OpenGL, Entity based, need to address frustum culling). It took just a couple of hours to figure out how OGRE draws and implement it. I could make a patch (very small diff) that includes a modified version of the Instancing Sample if it is not already integrated or if anyone wants to see another approach. [/Edit]

[sinbad]

No-one's integrated this yet. For years GL refused to support 'true' instancing so now they finally do (GL4 was the first time it's a required feature AFAIK?) it would be good.

[betauser]

You are my hero!

Thanks

[betauser]

We just released NeoAxis 0.85.

The new features are among others support for 3Dc texture format, automatic generation of True Type fonts, better Stencil Shadows and an update for the web player to version 1.2.
Additionally the exporters are enhanced and now support blending skeletal and morph animation.
You can see the full list of new features here:
http://www.neoaxisgroup.com/neoaxis/changelog

For the next release the we plans to release MaxOSX support and implementation of parallel split shadow maps.

You can download modified OGRE sources and use sources for your projects as reference.
As example i think 3Dc texture format implementation will be interesting.

[cyrfer]

I've been trying to figure out how OGRE makes the TrueType font-textures myself. I'm confused by the mapping used to bake the texture. I hope to look at your code soon. Thanks for sharing!

[betauser]

I've been trying to figure out how OGRE makes the TrueType font-textures myself. I'm confused by the mapping used to bake the texture. I hope to look at your code soon. Thanks for sharing!

No True Type code in the our OGRE sources, because we are using own realization for support TTF.

[Praetor]

Do you mean you actually generate TTF files, or you the GPU glyph textures from TTF?