[2.1] comment out a part of HLMS shader

What it says on the tin: a place to discuss proposed new features.
hyyou
Gremlin
Posts: 173
Joined: Wed Feb 03, 2016 2:24 am
x 17

[2.1] comment out a part of HLMS shader

Post by hyyou »

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

Code: Select all

//@insertpiece(some_pieces)
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:
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 169

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

Post by xrgo »

Yes I agree, what I do is to rename "some_piece" to "some_pieceASDF" which I am sure it doesn't exist
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5433
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1341

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

Post by dark_sylinc »

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)