[2.1] comment out a part of HLMS shader

What it says on the tin: a place to discuss proposed new features.
Post Reply
Posts: 141
Joined: Wed Feb 03, 2016 2:24 am
x 2

[2.1] comment out a part of HLMS shader

Post by hyyou » Sun Apr 24, 2016 2:18 pm

HLMS's preprocessor ignores syntax of C comment, such as in PixelShader_ps.glsl

Code: Select all

In the above code, Ogre's HLMS will still insert a piece. (notice the slashes //)

The technique to comment out some lines for debugging purpose is currently unusable.

It would be useful if you can add this feature - make HLMS recognize C-comment syntax and skip them. :mrgreen:
0 x

OGRE Expert User
OGRE Expert User
Posts: 847
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 38

Re: [2.1] comment out a part of HLMS shader

Post by xrgo » Sun Apr 24, 2016 3:04 pm

Yes I agree, what I do is to rename "some_piece" to "some_pieceASDF" which I am sure it doesn't exist
0 x

User avatar
OGRE Team Member
OGRE Team Member
Posts: 3523
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 77

Re: [2.1] comment out a part of HLMS shader

Post by dark_sylinc » Sun Apr 24, 2016 7:12 pm

From the manual:
The preprocessor was written with speed and simplicity in mind. It does not implement an AST or anything fancy. This is very important to account while writing templates because there will be cases when using the preprocessor may feel counter-intuitive or frustrating.
I wanted to use Lua or Python as a means of concatenating the string that would become the shader (e.g. executing PbsTemplate.lua / PbsTemplate.py which spit outs shader code); but that would've added a huge dependency, bloated our code, and have slow shader generation.

The parser is actually extremely simple and extremely dumb. So C-like parsing is nowhere near close. I did recall writing functionality for the Hlms to remove lines containing three slashes e.g.:

Code: Select all

///This whole line will not be included
But I don't know what the hell happened with it (may be it got shelved in Mercurial and then lost?).
The rationale behind it was that 2 slashes = comments useful in the generated output; 3 slashes = comments that only make sense on the template.

Like xrgo, I usually rename the pieces or the properties to something I'm sure doesn't exist, or if it's a property I can also add "&& false" which doesn't exist and if it were, it would be set to 0 (unless someone writes @pset( false, 1 ) which is the equivalent of doing #define false 1 in C/C++ just to screw with everyone)
0 x

Post Reply