future plans of ogre1.1x

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
frostbyte
Orc Shaman
Posts: 737
Joined: Fri May 31, 2013 2:28 am
x 65

future plans of ogre1.1x

Post by frostbyte »

hi paroj, i've seen that you started fiddling with PBS and i understand that you want to aband HLMS port and integrate PBS to RTSS, as i understand you're purpose is to allow PBS with gpu-skinning with all light-source types
was hoping you can expend a bit about this PBS pipeline...
i'm also interested to know if you plan to expend ogre1.1x pipeline further with modern light technique and tricks...
thanks...
the woods are lovely dark and deep
but i have promises to keep
and miles to code before i sleep
and miles to code before i sleep..

coolest videos link( two minutes paper )...
https://www.youtube.com/user/keeroyz/videos
paroj
OGRE Team Member
OGRE Team Member
Posts: 2093
Joined: Sun Mar 30, 2014 2:51 pm
x 1129

Re: future plans of ogre1.1x

Post by paroj »

looking on my GSoC proposals, you probably get the best idea where I want 1.x to go
viewtopic.php?f=13&t=93774

basically it is about keeping the stable foundation that runs everywhere while embracing some new things here and there.

Rearding the PBS pipeline: PBS is basically a "standardized" normal-mapping with some improved/ fixed lighting calculations. There really is not much magic behind it - just take a look at the PBS sample in 1.10.11.

But if you look at the current RTSS:
https://ogrecave.github.io/ogre/api/1.1 ... s_overview

you see that the texturing, lighting and coloring stages are strictly separated, which prohibits (or at least makes it very hard) to implement PBS in terms of RTSS.

The goal here is just to weaken the separation - either by allowing a RTSS "module" (SRS) to implement all 3 stages at once, or better by introducing requirements and capabilites to e.g. say "normal mapping requires per pixel lighting". (the current implementation just copy pastes per pixel lighting)

Ultimately you should be able to just say "physically_based" here:
https://ogrecave.github.io/ogre/api/1.1 ... ml#shading

or "cook_torrance" here:
https://ogrecave.github.io/ogre/api/1.1 ... ting_stage
frostbyte
Orc Shaman
Posts: 737
Joined: Fri May 31, 2013 2:28 am
x 65

Re: future plans of ogre1.1x

Post by frostbyte »

paroj wrote: Tue Feb 06, 2018 3:32 pm looking on my GSoC proposals, you probably get the best idea where I want 1.x to go...
expending the idea-discussion a bit to this thread...
Topic1: interoperability between the addons
suggesting this is a better path https://github.com/yoyTeam/BlendLoader ( ogre2.1 but actually works on v1:mesh )
i'd say its much faster and more reliable( uses blender-DNA ) and has less maintenance and version compatibility problems+ no need to download or mess with blender, just download from blendSwap or sketchFab and render it in ogre

Topic2: bring Ogre to the web
that would be awasome

Topic4: Configurable Pipelines with RTSS
paroj wrote: Tue Feb 06, 2018 3:32 pm The goal here is just to weaken the separation...
i was wondering if we can leech on other rendering projects, in particular i have in mind https://github.com/tobspr/RenderPipeline

back when i thought about porting it to ogre, i dived a bit into the code...
as i remember it was very "ogre-compatible"
beside some small features that panda has( IIRC something about passing matrix array to the shader ) it should be straight-forward to port( now that ogre has python it should be even easier )
unfortunately, i don't have time to mess with the renderer as its not my field of expertise( neither is python )
but i'm hoping to make a meaningful contribution to ogre once i have my commercial product running

the big advantage of this project is that it uses panda1.x minimastically just for getting some data and submiting the shaders
panda 1.x is very similar to ogre1.x anyway so it should be easy to port this project to ogre, which can bring ogre1.1x to a whole new level with the obvious advantage of no maintainance cost and with a top-end rendering pipeline features
its not perfect and targeting mid-high end gpu's with openGL4.3 but for low end gpus we have the regular ogre pipeline anyway
hope you can take a while to look into this idea, i think its very interesting anyway...

just to help you scan quickly the code:
IIRC most of the actual rendering code does'nt contain any panda specific calls( instead it submit rendering commands to a rendering command buffer which executes them using panda( it just uses panda as a rendering backend )
calls to panda's renderer are implemented in native( for c++ based modules ) and pynative( for python based ) folders
i think you can choose to use either c++ or python for most plugins with some exceptions
other than that its mostly gui, image loading etc...
shader preprocess is done by using opengl #pragma
if you want to try it out, i recommend using panda's prebuild nightly builds( should work out of the box )
https://github.com/tobspr/RenderPipelin ... %20Started

thanks :)
the woods are lovely dark and deep
but i have promises to keep
and miles to code before i sleep
and miles to code before i sleep..

coolest videos link( two minutes paper )...
https://www.youtube.com/user/keeroyz/videos