[News] Ogre 13.6 released

News, announcements and important global threads from the Ogre3D Team.
paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

[News] Ogre 13.6 released

Post by paroj »

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

In the news post you mention
"RTSS Terrain
Already mentioned in the 13.5 announcement, this has now finally landed. Thanks to the preliminary testing by the rigs-of-rods guys, the remaining bugs have been ironed out. This feature allows to easily enable multiple lights or switch to PBR equations altogether."

I would like to use PBS materials on the terrain along with point lighting, but I can't seem to find any examples of its implementation - point lights don't seem to work atall with my current config.

Are there any additional steps required to set this up and where can i find the example shown in the screenshot if atall?

Thanks in advance.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

I've also noticed the parallax mapping doesn't seem to work properly. Just get a strange "warping" effect instead. Normal mapping works just fine.

TIA

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

scratchyrice wrote: Tue May 09, 2023 4:33 pm

Hi Paroj,

In the news post you mention
"RTSS Terrain
Already mentioned in the 13.5 announcement, this has now finally landed. Thanks to the preliminary testing by the rigs-of-rods guys, the remaining bugs have been ironed out. This feature allows to easily enable multiple lights or switch to PBR equations altogether."

I would like to use PBS materials on the terrain along with point lighting, but I can't seem to find any examples of its implementation - point lights don't seem to work atall with my current config.

Are there any additional steps required to set this up and where can i find the example shown in the screenshot if atall?

Thanks in advance.

see this diff for the RTSS API of Terrain:
https://github.com/OGRECave/ogre/compar ... 108a7d4aba

that change reverts having two lights (directional + spot) back to the default of only one directional light.

to get PBR, you would modify that RenderState like here:
https://github.com/OGRECave/ogre/blob/8 ... #L564-L565

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

scratchyrice wrote: Tue May 09, 2023 7:01 pm

I've also noticed the parallax mapping doesn't seem to work properly. Just get a strange "warping" effect instead. Normal mapping works just fine.

probably the parallax mapping parameters work only well for the terrain demo.

They are currently hardcoded here:
https://github.com/OGRECave/ogre/blob/8 ... S.cpp#L266

things were like that since the inception of the Terrain Component, so I did not bother exposing this when refactoring to the RTSS

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Thanks for getting back to me!

Re terrain lighting that makes sense - I'm guessing it works only with spotlights and not point lights?

I have managed to get PBR working fine with all entities but not yet the terrain - I assume there is a terrain specific RTSS shader generator I need to hook onto or something? I'll have a play around with it.

Regarding the parallax mapping - from my understanding it is effectively offset mapping and so should make surfaces "stick out"?

On an entity I get this - notice how theres no difference - this is normal mapping vs parallax using rt_shader_system in the material.
Image
Image

With the terrain its much the same story - but for some reason when rotating the camera the terrain sort of "shifts" in the opposite direction to the direction i'm rotating the camera making objects above it look like they are floating. Again this only happens when parallax is enabled.
Image
Image

The scene only has one light source for 95% of the time - one directional light - does this make a difference?

If this is a bug I'm quite happy to have a go at fixing it myself - just want to confirm its not a setting I've missed or something.

TIA

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

scratchyrice wrote: Wed May 10, 2023 2:43 am

Re terrain lighting that makes sense - I'm guessing it works only with spotlights and not point lights?

no, you just have to explicitly enable point lights as in the linked diff. see:
https://ogrecave.github.io/ogre/api/lat ... c5acee656f

I have managed to get PBR working fine with all entities but not yet the terrain - I assume there is a terrain specific RTSS shader generator I need to hook onto or something? I'll have a play around with it.

scratchyrice wrote: Wed May 10, 2023 2:43 am

Regarding the parallax mapping - from my understanding it is effectively offset mapping and so should make surfaces "stick out"?

If this is a bug I'm quite happy to have a go at fixing it myself - just want to confirm its not a setting I've missed or something.

parallax mapping with terrain is actually the same code as parallax mapping with entities after the 13.6 refactor. see:
https://github.com/OGRECave/ogre/blob/c ... sl#L46-L48

So the different behavior must be either parametrization (as I hinted above) or viewPos being in the wrong coordinate system.

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

no, you just have to explicitly enable point lights as in the linked diff. see:
https://ogrecave.github.io/ogre/api/lat ... c5acee656f

Great thanks that works fine now.

Re parralax mapping - I will have a play with it. Whilst it doesn't produce the strange "warping" effect on entity's, it doesn't seem to actually be doing anything atall across the board including entities. It looks the same both as just normal mapping and with parallax - it doesn't really "stick out" atall with parallax on as i would expect. I've been reading into different parallax/offset mapping algo's so im going to try implement one of these into "SGX_Generate_Parallax_Texcoord" and see if it makes a difference.

Will be sure to post my result's with this once done.

Thanks!

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

I still stand by the parameterization. Check the bumpmapping sample, where it looks correct:

Image

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Thanks Paroj,

Im looking into that sample now and will compare the parameters in my project vs that using renderdoc to see whats going on.

Many thanks.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

Running render doc I have found the following:

When this is run in SGX_Generate_Parallax_Texcoord, something strange happens:
vec3 eyeVec = -normalize(viewPos);

Before the vector is normalized, viewPos has valid and expected x, y and z values. After this has been executed suddenly the x and y values are reset to 0? Is this a bug with renderdoc perhaps? Also, eyeVec does not return the correct normalized values. eyeVec.x and eyeVec.y are populated but calculated incorrectly, and eyeVec.z is set to 0, which based on the original viewPos input, is wrong.

If I remove the normalization - parts of the texture close to the camera look like parallax is working correctly, but afar is not which I'm assuming is down to lack of normalization.

I've not got to the bottom of it yet, but something seems off.

Thanks

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

Ah I believe the shader compiler is just optimizing those values out.

My scene is at a scale of 1 unit = 1 meter. I've noticed the parallax effect is far more noticeable at a distance. I have tried dividing the scale bias by 10 to compensate (most ogre samples are at roughly 10x the scale), but if anything - it looks even flatter. If i multiply the bias by 10, the warping effect is even more pronounced.

One thought is that isn't eye direction supposed to be based on the view direction from the camera to the fragment position - from what i can work out its based on the camera position to the vertex position. Is this what could be causing this flattening effect at smaller scales?

Thanks

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

I have done some further investigation, and have been using the ogre sample to do so.

I have taken screenshots side by side with just normal mapping, and then parallax mapping set. Even in the ogre sample there seems to be no difference and whilst normal mapping is working there doesn't seem to be any "depth".

I alternated the RTSS/OffsetMapping material to run these tests. I changed the line:
lighting_stage normal_map rockwall_NH.tga parallax
Backwards and forwards between that and
lighting_stage normal_map rockwall_NH.tga tangent_space 0 RTSS/NormalMapSampler

Parralax on:
Image

Normal mapping only:
Image

Parallax on:
Image

Normal mapping only:
Image

Parralax on:
Image

Normal mapping only:
Image

The first images are using the sample textures on this ogl parallax mapping tutorial:
https://learnopengl.com/Advanced-Lighti ... ax-Mapping

As in the screenshot on here I would have thought that with parallax mapping there would be far more "depth" without relying on specular like with normal mapping to give the perception of depth:
Image

Sorry - I'm not trying to be a pain! Just trying to get to the bottom of it as I would really like to get it working one way or another xD

Thanks again.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

found one bug by comparing the shader to that tutorial:
https://github.com/OGRECave/ogre/pull/2838/files

before/ after:
Image Image

probably there are more..

however, this specific one was already correct with Terrain

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

Thank you for this. I have updated my copy of ogre with this.

Correct me if I'm wrong but from what I can work out the view direction is not being calculated correctly which would explain the strange warping effect with larger scale numbers and it not looking particularly "bumpy"? I'm trying to make heads and tails of the shader generation code - I can't figure out if the TBN is being calculated anywhere in the vertex shader or not? For the effect to work properly do we not need the tangent view position, and the tangent fragment view position? Are these calculated in the vertex shader? Looking at the renderdoc outputs I can't see any reference to TBN or output of these two values.

With these two values the view direction could be calculated more accurately producing a much better result. Correct me if I'm wrong - But that's my understanding of it - as at the moment from what i can figure out its just taking the position of the camera relative to the vertex, rather than the fragment and inversing it.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

Yeah, currently the view-space "view" is used to compute the displacement. Probably it should be in tangent space as in the tutorial.
You could give it a try, as I will be busy in the next days.

TBN is computed in the fragment shader here:
https://github.com/OGRECave/ogre/blob/b ... p.glsl#L52

Note that the tutorial uses world-space vectors, while I am using view-space vectors in Ogre, which is why the vectors are calculated differently.
Using the view-space is numerically more stable and typically simpler.

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

Thanks for the pointers. I will give this a go.

I want to give back to the project if I can - how would be best for me to send the update when working?

Thanks.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

scratchyrice wrote: Thu May 11, 2023 3:14 pm

I want to give back to the project if I can - how would be best for me to send the update when working?

a pull-request on github ;)

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

Cool - will do when done.

Have got the basic parallax effect working properly now. Its far from optimal, but it works. Ideally the TBN should be calculated in the vertex shader for performance, so once i've tidied it up ill work out how to do this. Am slowly getting to grips with the shader generation code.

Here are some shots - The higher the heightscale - the more "depth" results.
Heightscale 0.04:
Image
Image

Heightscale 0.1:
Image
Image

Original:
Image
Image

There were two issues preventing it from working correctly. Firstly, the eye vector was not being calculated correctly. Secondly the parallax texture coords need to be calculated before normal mapping is calculated in order for the parallax effect to be applied to both normal and diffuse mapping.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

scratchyrice wrote: Thu May 11, 2023 9:11 pm

Ideally the TBN should be calculated in the vertex shader for performance, so once i've tidied it up ill work out how to do this.

I am not sure there will be any measurable performance benefit justifying the hassle. Yes, we would safe some duplicate computations by this, but they are all diminished by that extra texture fetch or even by evaluating one additional light.

scratchyrice wrote: Thu May 11, 2023 9:11 pm

Secondly the parallax texture coords need to be calculated before normal mapping is calculated in order for the parallax effect to be applied to both normal and diffuse mapping.

thats what I tried to fix here: viewtopic.php?p=554558#p554558
I fixed the issue in renderdoc, but forgot to move the critical line:
https://github.com/OGRECave/ogre/pull/2839/files

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

paroj wrote: Thu May 11, 2023 11:38 pm

am not sure there will be any measurable performance benefit justifying the hassle. Yes, we would safe some duplicate computations by this, but they are all diminished by that extra texture fetch or even by evaluating one additional light.

Okay well i will leave it in the ps in that case and possibly modify in future if it does become and issue. How about calculating the tbn outside of the normal and parralax functions, that shouldnt be too much hastle?

Im currently updating it to parallax occlusion in order to remove as many of the strange artifacts at sharp angles as possible.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

scratchyrice wrote: Thu May 11, 2023 11:47 pm
paroj wrote: Thu May 11, 2023 11:38 pm

am not sure there will be any measurable performance benefit justifying the hassle. Yes, we would safe some duplicate computations by this, but they are all diminished by that extra texture fetch or even by evaluating one additional light.

How about calculating the tbn outside of the normal and parralax functions, that shouldnt be too much hastle?

yes, this should be fine. Feel free to create PR as soon as you got someting. Its easier to discuss code over at github.

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

paroj wrote: Fri May 12, 2023 12:44 am

yes, this should be fine. Feel free to create PR as soon as you got someting. Its easier to discuss code over at github.

Of course - will do. To be honest im not very well versed with git, i tend to fly solo so not had much experience with it. I'm guessing I will need to pull a fresh copy of the latest ogre repo (Im on 1.3.6 - not the latest) - make the changes to that and then push back to you.

I have steep mapping working well now, and have moved the TBN calcs out of the normal and parallax functions. Hopefully will be all done tomorrow with the smoothing working for full occlusion mapping. Would it be best to have some kind of separation between "standard" parallax and occlusion as occlusion is more computationally expensive.
Image
Image

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: [News] Ogre 13.6 released

Post by paroj »

scratchyrice wrote: Fri May 12, 2023 4:21 am
paroj wrote: Fri May 12, 2023 12:44 am

yes, this should be fine. Feel free to create PR as soon as you got someting. Its easier to discuss code over at github.

Of course - will do. To be honest im not very well versed with git, i tend to fly solo so not had much experience with it. I'm guessing I will need to pull a fresh copy of the latest ogre repo (Im on 1.3.6 - not the latest) - make the changes to that and then push back to you.

Yes, this change should go into master (to be 14.0) as it is too invasive for 13.6. I backported the normal map lookup for 13.6.5 though as it is not user visible (no shader and no API changes).

As for the git part, here is a rough summary of what to do:
https://gist.github.com/Chaser324/ce0505fbed06b947d962

If you would rather use an UI, I can recommend using vscode with this extension:
https://marketplace.visualstudio.com/it ... .git-graph

scratchyrice wrote: Fri May 12, 2023 4:21 am

I have steep mapping working well now, and have moved the TBN calcs out of the normal and parallax functions. Hopefully will be all done tomorrow with the smoothing working for full occlusion mapping. Would it be best to have some kind of separation between "standard" parallax and occlusion as occlusion is more computationally expensive.
Image
Image

yes, texture lookups tank performance on mobile, so it would be better to still offer the simple method.
You could add a new method called "parallax_steep" here for this:
https://github.com/OGRECave/ogre/blob/6 ... #L176-L180

scratchyrice
Gnome
Posts: 358
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England
x 15

Re: [News] Ogre 13.6 released

Post by scratchyrice »

Hi Paroj,

Im happy with how it works and looks now:
Video:

Image:
Image

I just need to add in the extra parallax steep option, and get it working with terrains now.

Once thats done I'll set up git and push it to you.

Intel i7 4790k, Gigabyte Nvidia GeForce 3080 10GB, 16GB DDR3

Post Reply