Ogre2.1 render-pipeline( "insperational project" )

[frostbyte]

https://github.com/tobspr/RenderPipeline/wiki/Features
https://www.youtube.com/user/tostbrot21
What? : this developer( kudos ) is secretly turning panda3d into ogre2.1++ (-:
ogre2.1++? : VXGL( voxel cone tracing ) , ssr/sssr , Volumetric voxel based clouds, Volumetric Lighting and other cool stuff (-:
Port to ogre? : it might be easier to port a clean nvidia opengl demos then porting a python based panda3d , but maybe we can still borrow some stuff...

i took a deep look at the "render-pipeline" code and its quite similar to ogre'2.1 way of doing stuff
i must say i never wrote python code and never used panda3d but instalation of panda and the render-pipeline+samples was quick and painless...
it took me only a couple of hours to understand the python code and program flow( damm, python is easy... )

happy coding (-:

note: this project is still experimental so some features don't have samples yet( heard that the dev is'nt quite happy with the performance/results... ),
i also see some youtube clips have been removed( nice volume Clouds/light scatering/godray/terrain clips... )

[rujialiu]

Cool! I only used panda3d many years ago. Didn't know this project until now. tobspr is really doing a good job.

About features: I already made several post recently about Environment Probes and SSR, seems that they're not difficult to do in Ogre (though they're not usable out of the box).
But Voxel cone tracing & Subsurface shading & Volumetric lighting seem to need considerable work...

[rujialiu]

Skimmed over the implementations of some features I'm interested. Looks like it has a really flexible plugin system, so things like vxgi, ssr and volumtric can all be implemented as plugins with short python codes and shaders. I wonder whether Ogre's plugin system is also flexible enough...

RenderPipeline seems to support OpenGL only (didn't see any HLSL/GLSLES/metal shader), maybe that makes the plugin system a lot easier?

[frostbyte]

ogre2.1 is a "focus shift" to the "rendering pipeline" so i think render-pipeline features should be avail "out of the box"
but since this luxery features are low priorities for now, it could be nice if community will help itself here...
it could be useful and fun switching between different alternative pipelines enabling and disabling features...

maintining one shader codebase is for sure easier...waiting for spirV to save us...
https://github.com/KhronosGroup/SPIRV-Cross
https://github.com/KTXSoftware/krafix

i did'nt see anything in his code that ogre can't easily do...( besides setting shader params which is more advanced with panda3d )
he's plugin system resembles ogres Compositor+setting shader params
instead of hlms pieces he uses "#pragma include"
on most plugins beside the deferred lighting/shading stuff he is using the gBuffer only to get depthFromPosition
i think dark_sylinc showed how to do this without a gBuffer( so it can run with forward3d )
and besides ogre2.1 already has an experimental hlms-deferred-pbs pipe...http://www.ogre3d.org/forums/viewtopic.php?f=11&t=85638

personaly i think tobspr render-pipeline would work better with ogre( stabler/faster )
i'm sure "out of the box features" will slowly but surely arrive to ogre2.1 but anyway it's a nice code-reference...

[rujialiu]

maintining one shader codebase is for sure easier...waiting for spirV to save us...

oh yes... is there any change Ogre will support it in near future (about 1 year)?

i did'nt see anything in his code that ogre can't easily do... he's plugin system resembles ogres Compositor+setting shader params
instead of hlms pieces he uses "#pragma include"
...
personaly i think tobspr render-pipeline would work better with ogre( stabler/faster )
i'm sure "out of the box features" will "slowly but surely" arrive to ogre2.1 but anyway it's a nice code-reference...

Nice to hear that.
Though I'm still new to Ogre 2.1 at this moment, I'll probably be able to port some of these features to Ogre some day. I know that core Ogre team members have more important things to do

[frostbyte]

about spirV transpilers, we'll just have to wait and see how that turns out( i guess it will be ok for general use, no vendor specific stuff etc.. )
yeah,well we are all sort of new to Ogre2.1 (-:
hopefully, some day i will also have enough time to have some fun with HLMS, Advanced features and porting stuff (-:

[tobspr]

Hey everybody,
thanks for the interest in my project!

note: this project is still experimental so some features don't have samples yet( heard that the dev is'nt quite happy with the performance/results... ),
i also see some youtube clips have been removed( nice volume Clouds/light scatering/godray/terrain clips... )

Indeed its still a bit experimental, although its already quite useable Some newer features like Volumetric clouds still have some performance issues, though, as you mentioned
I didn't remove any videos, do you have any particular video in mind?

RenderPipeline seems to support OpenGL only (didn't see any HLSL/GLSLES/metal shader), maybe that makes the plugin system a lot easier?

The render pipeline plugin system is so simple, because it already uses Panda3D as an abstraction layer. Since Panda3D handles all platform/api dependent code, the plugin system can be much simpler.
The only reason that the render pipeline does not support Direct3D is, that not all required features are implemented in panda yet - If it would be supported, the render pipeline could run with almost the same code on Direct3D 11/12, too.

personaly i think tobspr render-pipeline would work better with ogre( stabler/faster )

I'm don't think thats the case, since the Render Pipeline only uses a small part of Panda3D. 95% of the work is done in shaders on the GPU, and the 5% CPU side code is raw C++. The python code only setups the render targets and connects the required shader inputs and textures, but it does not do many performance critical operations


If there are further questions, I'd be happy to answer them

[frostbyte]

wrote long reply...got deleted...sign to make it shorter...

OMG, tobspr joined Ogre community, Welcome...
i feel Ogre2.1 is really a better fit for your needs...try it... (-:
Ogres HLMS+compositor ~= RenderPipeline, so you get supported at mainStream( shader combine/enable/disable/reload and much more... )
Stabler: matias( aka dark_sylinc ) is doing an amazing job at keeping ogre2.1 RenderSystems( DX11,GL3+ ) feature rich, stable and optimized while targeting common hardware( ogre2.1 runs perfect on my HD4000 ) and preparing for the future( now targeting Metal )
Faster: the same dark_sylinc have also refactored Ogre2.1 with some agressive optimizations( AZDO, fast culling, vertex compressiom,tex array/atlas etc... )

RenderPipeline crushed my laptop( nvidia 660m ) a lot, i blame panda3d...
RenderPipeline voxel cloud, vxgl(sponza) samples available somewhere/somewhen?
my gpu is struggling( low fps ) , is the RenderPipeline targeting towards high end gpus only?

great code, great contribution, thanks for replying, have func...(-:"

edit: some interesting reading stuff http://advances.realtimerendering.com/s ... 20ARTR.pdf

[rujialiu]

Hey everybody,
thanks for the interest in my project!

Welcome!!!

I'm don't think thats the case, since the Render Pipeline only uses a small part of Panda3D. 95% of the work is done in shaders on the GPU, and the 5% CPU side code is raw C++. The python code only setups the render targets and connects the required shader inputs and textures, but it does not do many performance critical operations

I don't know whether frostbyte is thinking about the same thing, but I would say, "faster/more stable" is more about panda3d vs ogre 2.1, not Render Pipeline itself. For example, since Ogre 2.1 had a bunch of low-level optimizations, you might get more frame time to spend on GI

If there are further questions, I'd be happy to answer them

I never expected you come here because you seem to be a huge fan of panda3d. You even said (somewhere) that you even prefer implementing features in panda3d instead of UE4
That's why I wrote you private emails and did not mention I'm using Ogre.
Thanks for replying my emails and I'll ask more questions here instead, so that frostbyte and other people can join the discussion.

[tobspr]

OMG, tobspr joined Ogre community, Welcome...
i feel Ogre2.1 is really a better fit for your needs...try it... (-:

Thanks Well I'm quite happy with Panda3D at the moment

my gpu is struggling( low fps ) , is the RenderPipeline targeting towards high end gpus only?

The default configuration targets higher end gpus, but by changing plugins and disabling them, it can also run on lower end gpus, like an intel hd.
If you have a low end gpu then you have to change the settings, otherwise it will of course overload your GPU

I already read that paper you linked, and its a great resource for voxel clouds

For example, since Ogre 2.1 had a bunch of low-level optimizations, you might get more frame time to spend on GI

To be honest, I doubt this, since 99% of the time is spent on the GPU, so you won't get any advantage. But I don't want this thread to get a discussion about Panda3D vs Ogre

Well yeah I'm a fan of Panda3D, but I thought it wouldn't hurt to answer some questions

[frostbyte]

sorry- did'nt mean to make it sound like ogre vs panda, i don't believe in such comparisons, each library has its faults and virtues...
don't really care much about the engine used in this case, but about the RenderPipeline and its cool shader stuff...clouds in particular (-:
besides that, i think this kinds of open source projects are a great learning resource for modern game rendering architecture
reading RenderPipeline codes actually helped me to better understand Ogres HLMS/Compositor purpose and usage

thanks, cheers (-: