Horde3D

Spent the weekend playing with Horde sources and want to say that I really like the design of the engine.

I would like to contribute so what is the best way to go ?

Currently my roadmap is (working in the spare time so it may take some to implement :
1.Rendering
a. remove calls to glCopyTexSubImage2D completely. It's the performance killer on NVidia cards, while experimenting I've removed this call for sharp shadows and got 250% FPS increase
b. implement PSSM for sharp shadows from large-scale lights
c. implement more perceptually correct scheme for soft shadows
d. post-process filters
e. improve font rendering
2. Animation
a. add inter-frame interpolation
b. expose joints through API with the possibility to get current joint orientation and add secondary motion to joint
3. Scene management
a. HW occlusion culling (outdoor and indoor variants), also make use of temporal coherency when performing frustum culling
b. possibility to attach nodes to joints
4. Engine
a. unify configuration capabilities between XML, API and possible scripting language bindings
b. implement bindings for Squirrel
5. Performance
a. Chicago sample with >30 FPS on GeForce 6600

_________________
--Anatoly

Hello Anatoly, welcome to the Horde3D community!

I'm glad to see that you like the design of Horde3D and I am happy that you want to contribute to this ambitious project. Your roadmap sounds very promising, all of the points are important to the engine.

Funny thing, yesterday I read the paper about PSSM (Parallel Split Shadow Maps) for the first time and thought that this would be a cool thing to integrate in Horde3D, especially since the quality/complexity tradeoff seems to be very good and some nice demos are available on the net. Convincing shadows are a really important issue but I have to work on other things first that my university needs for some projects.
So would you be interested in implementing a better and maybe faster (as you noted correctly glCopyTexSubImage2D is slow) shadowing solution at first? I would greatly appreciate that!

I think the code of the current release 0.6.1 is a good starting point for that and in the near future I can also set up a subversion server.

Thanks for offering your help!

Nicolas

Hi, I am very interested in this project an I am also considering using it for future projects and contributing to the renderer.

I was wondering if there are any plans to add translucency?

If I require translucency would I have to add it in myself (this isnt too much of a problem. I'm tryingto figgure out a neat solution for transulcency and deferred lighting...).

@marciano: Yes, SVN would be great.

Last night I've played with different approaches to soft shadows without screen-space blur. Here is what I've got:
1. Horde3d 0.6.1 as reference - soft shadows from single light source

2. Modification - sharp shadows from the both lights

3. Modification - soft shadows from the both lights.


The need in PSSM is clearly visible I've started to implement it yesterday and hope to have something at the weekend at least.

@DarkAngel:
Thought about translucency too but didn't came to any satisfying idea yet - all I could imagine require much more additional passes than would be practical.

_________________
--Anatoly

Great that you already found the time to experiment a bit

The framerate of your soft shadows is much better but the screen space blur shadows are still looking quite a bit softer. Maybe we can find some tricks to increase performance for them. I'm really looking forward to see the PSSM in action since I guess that they will dramatically increase the shadow quality.

About the translucency. Maybe I will also need it for a project pretty soon but that's not yet certain. The only way that I can think of at the moment is to render the translucent geometry in a seperate pass using standard forward shading. That would mean that the translucent objects can't receive shadows but I think that's not so much of a problem.
If anyone has a better idea I would be curious to hear it!

No PSSM yet but rather good (I think compromize between softness and performance. Shadows are more sharp at feet as should be.


PSSMs are mostly implemented but need debugging/tweaking, currently the picture is weird

_________________
--Anatoly

Good work Anatoly!

Performance is obviously much better (assuming you still use a 1024 shadow map) and the edges look soft enough.

What technique are you using? Is this PCF with a special filter kernel?
I was experimenting a bit with VSM (Variance Shadow Maps) before doing the screen space blur implementation but the shadow bleeding was not acceptable in the city scene that is also shown on the screenshot page.

Btw, the next thing for me to implement are morph targets to enable lip synchronization.

Thanks

Yes it's a PCF with varying kernel size. Size depends on the ratio of distances from the light source to shadow caster and receiver and the virtual "size" of light source itself. There is still some room for performance improvements - need to reduce the number of shadow map lookups, but the quality is almost satisfying, especcialy when everything moves

I've tried VSM - they are much faster as only one texture lookup is needed, but the image quality isn't anywhere close to PCF's (or maybe I've missed something in the paper and implemented them incorrectly).

_________________
--Anatoly

Have you blurred the shadowmap when using VSM? This is where the softness comes from, but of course you need some more lookups again for the blurring. The quality was ok in my implementation except for the annoying light bleeding which made it inacceptable for some scenes.
Probably you know the NVidia presentation about VSM but if not here is the link:

http://developer.nvidia.com/object/variance-shadow-maps-gdc-2006.html

It shows quality/performance comparisons between VSM and PCF.

Actually I think you are on a good track with your current implementation. As far as I know there are also some tricks for PCF which use a special kernel layout to reduce texture lookups. Are you already using bilinear interpolation for the PCF? And which is the maximum size of your kernel?

Spent the weekend strengthening the glass cover on my "home office" on the balcony - hope to continue working there even when -30 outboard

VSMs: didn't see that presentation but I've based my implementation on the paper by the same author from the NVSDK. However, reading PPT I've got some ideas about what was wrong in my shaders' code and shall try to fix them. If everything goes right then we would be able to use faster VSMs for "far" receivers and switch to better looking PCF when receiver is closer to camera, thus improving performace.

Max PCF kernel size in my shader is 6 for the most soft shadows but "average" (I beleive ) is 4.

Going to release my code somewhere near the thursday.

_________________
--Anatoly

I like the new shadow screenshots!


Yeah, thats pretty much what I was thinking of doing.
The graph structure might need some tweaking for optimal performance - for example a node might be given a "translucent" flag, and when this flag is set it also tells its parent node to set a "translucent child" flag, so that when rendering the second pass you can ignore most nodes that dont have the "translucent" or "translucent child" flags active.


[edit]BTW, I have been using Horde3D with the Code::Blocks IDE and a standard GNU compiler on windows. It took a bit of work to set up the workspaces/project files but it compiles fine! I think this means you should easily be able to port your engine to other platforms with GNU compilers (eg linux)

I'm glad that it usually doesn't get that hard here in Germany


Some optimizations for the scene graph would be important. It already has some flags that determine the rendering order but they are not yet activated. Performance optimization is something that I planned to do when more of the features are implemented.

Great to hear that Horde3D works well with other compilers.
Someone has already offered to do a Linux and Mac port in the future, I hope that this will work out and that we can look forward to see Horde3D running on other patforms.

Yesterday I have finished a basic morph target implementation, meaning that the engine will have support for facial animation and lip synchronization quite soon.

Sorrily, the release has to be delayed due to some oddities from our management and legal departments (they don't like *GPL, maybe I even shall have to reimplement the rendering part and release it under BSD or zlib license, on the other side - it may lead to open sourcing the entire engine, the way I would prefer)

Meanwhile, I'm experimenting with HW occlusion.



I've added "shadow receiver" and "shadow caster" flags to mesh nodes.



Great work! How do you deal with normals when applying morphs ?

_________________
--Anatoly

That's really sad but of course it's not your fault
Actually I thought you are doing the modifications in your spare time. I don't quite understand what you mean by "open sourcing the entire engine". Does that refer to an engine that your company is developping?
If your company has problems with the LGPL (which I think is actually a pretty fair license), there is theoretically still the option of dual licensing although I didn't think too much about the conditions yet.

Back to the coder's part. I already have a working HW occulsion culling implementation in my previous engine. I just didn't include it in Horde3D yet but that shouldn't take too much time. So you don't necessarily have to do research in that area.

Currently the morph targets are just interpolating positions. I intended to use them primarily for facial animation where vertices are only moved a bit and I think that the normals don't change that much. But I have to check this as soon as I get my test models. Adding normals for the morphers is no problem since the interpolation is done in software and is thus completely orthogonal to the rest of the animation system.

It was so two weeks ago but since then I was stupid enough to show the demo to my boss... Then he was stupid enough to tell about it to our investors in Moscow. Currently everything is heading towards the development of the online VR chat/game for our MetroEthernet. Nothing is set in stone, but they had asked me not to publish anything until all "consulting" will finish. Actually, I wasn't contracted to do what has been done and may do whatever I like with that code but that's a possibility to receive some backing for my project so I'll rather play with them and see what happen. On the other hand, it may easily end in nothing and I'll be free again It was said that definitive decision will be made this week.

About *GPL - I have the feeling that they are just afraid of these letters and won't dig deep into differences between LGPL and GPL itself. Honestly, it's the first time I see people here in Russia so concerned about open source licenses - usually it's taken much lighter here

About dual licensing - how do You feel about the MPL ? It protects the authors and at the same time allows whatever usage of the code.

Back to the technical side ...

Which method do you use ? I'm going to implement the algorithm described in this paper. I'll use Kd-tree for spatial subdivision - it will be useful everywhere where we need to depth-sort meshes (translucency, shadow map rendering) or faster frustum culling.


It will be OK when viewed from the distance but in close-up scenes faces will be looking "flat" without normal adjustments. One approach is to have normal map for each morph and blend them too, but that would limit the number of simultaneous morphs.

_________________
--Anatoly