Ogre3D shadow type naming

[Lumberjack]

The current Ogre3D basic shadow commands should be cleaned up a little bit without adding real new features.

The command "#PB_Shadow_TextureModulative" should be implemented as a command. It's part of the PB-Ogre3D system anyway (as far as I can tell) since the Character sample uses it with the constans "5" instead of the command name.

#PB_Shadow_Modulative and #PB_Shadow_Additive should be renamed to #PB_Shadow_Stencil_Modulative and #PB_Shadow_Stencil_Additive since that's what they are and it's more descriptive. Plus if we call the "texture shadows" -> "texture" inside the command the same logic should be applied to the stencil shadows for consistency.

My suggestion for the shadow type names:

#PB_Shadow_None

#PB_Shadow_Stencil_Modulative
#PB_Shadow_Stencil_Additive

#PB_Shadow_Texture_Modulative
#PB_Shadow_Texture_Additive

----------------------------------------

Thanks for your consideration,
Lumberjack

[Krix]

Hm...

[Bananenfreak]

+1

[Comtois]

It's implemented, Fred forgot this constant

Code: Select all

#PB_Shadow_TextureModulative = 5

For Information : stencil shadows will be removed in future versions of ogre (obsolete)

[Samuel]

For Information : stencil shadows will be removed in future versions of ogre (obsolete)

I agree with this move. Stencil shadows are just too slow for large scenes.
Texture shadows are the way to go in this day and age.

[Krix]

It's implemented, Fred forgot this constant

Code: Select all

#PB_Shadow_TextureModulative = 5

For Information : stencil shadows will be removed in future versions of ogre (obsolete)

That's great news. But when will that happen? I don't think it's anytime soon. And why not clean up the commands of the features already implemented?
PureBasic suppose to be one of the best (not mainstream) feature rich language out there with multi-OS support. So let's not leave features in without associated commands.
And let's make the commands clear and not misleading.

[AndyLy]

I do not understand: #PB_Shadow_Modulative will be deleted ?
If so, this is bad news, only this type of shadows I could get to work normally (in game) .

[Samuel]

The texture shadows in Purebasic are harder to set up compared to the stencil shadows because you need to specify which entities are receivers and which ones are casters. We can do this with EntityRenderMode().

For example lets say we have a cube hovering over a plane and we wish to have that plane receive texture shadows from the cube.
We'll use EntityRenderMode(#Plane, 0) to set the plane as a receiver. From then on all entities that are not also set as receivers will cast a shadow onto the plane.
There are ways to make entities receivers and casters, but as far as I know this is not possible in Purebasic, yet.

Here's a little bit of info on why stencil shadows are worse then textures shadows.

The disadvantages of stencil shadows are numerous though, especially on more modern hardware. Because stencil shadows are a geometric technique, they are inherently more costly the higher the number of polygons you use, meaning you are penalized the more detailed you make your meshes. The fillrate cost, which comes from having to render shadow volumes, also escalates the same way. Since more modern applications are likely to use higher polygon counts, stencil shadows can start to become a bottleneck. In addition, the visual aspects of stencil shadows are pretty primitive - your shadows will always be hard-edged, and you have no possibility of doing clever things with shaders since the stencil is not available for manipulation there. Therefore, if your application is aimed at higher-end machines you should definitely consider switching to texture shadows

[AndyLy]

Stencil shadows are just too slow for large scenes.

#PB_Shadow_Modulative FPS 60+
#PB_Shadow_TextureAdditive FPS `40
#PB_Shadow_Additive FPS `20

Do they really deserve to delete ? Let them remain . More choice for the user .

[Comtois]

I do not understand: #PB_Shadow_Modulative will be deleted ?
If so, this is bad news, only this type of shadows I could get to work normally (in game) .

I was talking about Ogre (from version 2.0), not PB. I do not know when PB will use this version. Ogre 2.0 will remove and change lot of things.

[Comtois]

Extract from Ogre 2.0 Porting manual :

Stencil shadows and “textured shadows” have been removed from Ogre 2.0; only depth shadow maps are supported.

[Samuel]

I see, but if I remember correctly depth shadow maps are shader based.

Does that mean purebasic will have a basic depth map shader built in? Or would we be allowed to use our own shadow shaders?
I know the latter needs self shadowing to be turned on, within OGRE, in order for our material scripts to have an effect.

I know this is something that won't happen for while. So maybe you don't have answer yet as to how you will handle this or if it will even be addressed.
I was just a bit curious is all.

[Samuel]

This is a bit off topic. So, sorry in advance.

Ogre 2.0 will remove and change lot of things.

After hearing this I decided to check out 2.0, as I haven't heard much about it, and man there are a lot of nice changes.

One of the more interesting things is the high possibility of dropping DirectX 9. Which pretty much kills off all XP users.
But I think it's for the best. Things need to move forward and you can't always keep things backwards compatible.

[PMV]

Just my opinion:

OGRE 2.0 is still under development and will be for a much
longer time. It is even planed that big features from OGRE 1.9/10
will be delayed for later versions to be reworked. That in mind
OGRE 2.0 should maybe skipped till 2.1a or 2.1b.
> OGRE 2.0 Roadmap

That said, it will take years till it bother us.
(or PB could support 1.9/10 and 2.0 )


MFG PMV

[Bananenfreak]

Code: Select all

 Or would we be allowed to use our own shadow shaders?

I hope so. Perhaps a few examples for it in Examplesfolder, but support for this. Receiver and caster at same time ftw.