1273 replies to this topic

[myconid]

ribez, on 17 October 2012 - 10:57 AM, said:

Just a question: it's possible to set the fog locally? i'm asking if is possible adding fog only around a river or a lake, or to the heights of a mountain

No, the postproc manager only does global effects.

Spahbod, on 17 October 2012 - 03:52 PM, said:

Can we use these in random maps?

No, but a script interface is a must-have.

[Enrique]

I'm having lots of fun with the post processing manager!!

I made night settings version of Belgian bogs and played against the AI. It turned out quite fun

Attached Thumbnails

• 
• 

[myconid]

Whoa Enrique, I wanna play that!

I wonder if we could use "black fog" to limit visibility in nighttime maps.

[Enrique]

myconid, on 17 October 2012 - 04:25 PM, said:

Whoa Enrique, I wanna play that!

I wonder if we could use "black fog" to limit visibility in nighttime maps.

That's what I did it makes a nice effect

EDIT: Commited if you want to try it

[fabio]

myconid, on 17 October 2012 - 04:01 PM, said:

Looks like the X1600 doesn't support OpenGL 2.1.

On Mesa R500 has complete OpenGL 2.1 (the hardware doesn't support NPOT textures, but they are implemented in software, the only problem is a slowdown when they are used). It's likely a driver bug however.

[myconid]

fabio, on 17 October 2012 - 04:31 PM, said:

On Mesa R500 has complete OpenGL 2.1 (the hardware doesn't support NPOT textures, but they are implemented in software, the only problem is a slowdown when they are used). It's likely a driver bug however.

IIRC, the 2.1 standard requires at least 32 register slots, and according to those errors your hardware doesn't have enough. The driver may provide 2.1 functionality, and maybe some of the higher-end models in same GPU series have the hardware support for it. I guess that's what they mean with the "it's not a bug, do not report it" thing.

Anyhow, if your driver doesn't report the number of slots, you can find it by sticking this somewhere in the engine's graphics code:

GLint v;
glGetIntegerv(GL_MAX_VARYING_FLOATS, &v);
std::cout << "SLOTS: " << v << std::endl;

[fabio]

Hmm, I'll try tomorrow with my current driver (from mesa 9.1) but according to the 0 A.D. OpenGL capability report for GL_MAX_VARYING_FLOATS_ARB (although it's not updated since long) all ATI cards have at least 32 slots (or also 40 on some version of RV530, my codename).

EDIT: also that error message only appears with glsl mode, while the corruption happens also on standard mode.

Edited by fabio, 17 October 2012 - 05:46 PM.

[fabio]

The WPOS error:

Quote

r300: ERROR: FS input WPOS unassigned, not enough hardware slots. (it's not a bug, do not report it)

is triggered by this code: http://cgit.freedesk..._derived.c#n552

while

Quote

r300: ERROR: FS input generic 20 unassigned, not enough hardware slots (it's not a bug, do not report it).

with: http://cgit.freedesk..._derived.c#n488

Edited by fabio, 17 October 2012 - 06:06 PM.

[myconid]

I see. The bit we care about is the "tex_count < 8" test. Without looking too deep into that code, I assume it's a hardcoded limit on the number of texcoord vectors (ie. hardware-interpolated 4-float registers). That's probably 4*8=32 floats. Probably. It could well be the case that with all the effects enabled the shaders compile to >32 varyings (worth trying lower values for materialmgr.quality in your config, to see if that helps).

Also, you mention that these errors are caused by preferglsl=true, not the postproc, however note that the postproc shaders always use GLSL (and we shouldn't discount that there may be something broken with the GLSL implementation you use). Let's see if other people experience similar issues...

Anyway, I'm afraid I can't for the life of me guess what might be going wrong from your screenshot. Maybe it could help a bit if you described how things change as you change the postproc settings.

[Mythos_Ruler]

Question: Would it be possible to make particles (smoke, etc., but not fire) cast shadows and be affected by sun/ambient color? I know this is a relatively new thing and I'm not sure if possible with OpenGL (I remember seeing screenshots of it for the latest version of DirectX).

[myconid]

Mythos_Ruler, on 18 October 2012 - 05:00 PM, said:

Question: Would it be possible to make particles (smoke, etc., but not fire) cast shadows and be affected by sun/ambient color? I know this is a relatively new thing and I'm not sure if possible with OpenGL (I remember seeing screenshots of it for the latest version of DirectX).

Affected by lighting: yes. Cast shadows: no yes, maybe (the shadowmapping technique we use can't handle transparent objects - you're right that DirectX 11/OpenGL 4.3 have some tricks for that, though - actually, newer APIs aren't a requirement, and there are techniques that we could try!).

[Mythos_Ruler]

myconid, on 19 October 2012 - 05:30 PM, said:

Affected by lighting: yes. Cast shadows: no yes, maybe (the shadowmapping technique we use can't handle transparent objects - you're right that DirectX 11/OpenGL 4.3 have some tricks for that, though - actually, newer APIs aren't a requirement, and there are techniques that we could try!).

Great news. It's not an important thing, of course, but it's one of those things that stand out from time to time (smoke not casting shadows, etc.).

[fabio]

(Sorry for the delay)

myconid, on 17 October 2012 - 06:40 PM, said:

I see. The bit we care about is the "tex_count < 8" test. Without looking too deep into that code, I assume it's a hardcoded limit on the number of texcoord vectors (ie. hardware-interpolated 4-float registers). That's probably 4*8=32 floats. Probably. It could well be the case that with all the effects enabled the shaders compile to >32 varyings (worth trying lower values for materialmgr.quality in your config, to see if that helps).

The error just appears with preferglsl=true (and no other settings), even if I add materialmgr.quality=0.0

Quote

Also, you mention that these errors are caused by preferglsl=true, not the postproc, however note that the postproc shaders always use GLSL (and we shouldn't discount that there may be something broken with the GLSL implementation you use). Let's see if other people experience similar issues...

Anyway, I'm afraid I can't for the life of me guess what might be going wrong from your screenshot. Maybe it could help a bit if you described how things change as you change the postproc settings.

Without preferglsl=true:
Removing <PostEffect>hdr</PostEffect> from Zagros Mountains 01 removes the corruption. However I cannot notice any other effect (fog included). No errors are printed (also with hdr restored).

With preferglsl=true:
Removing <PostEffect>hdr</PostEffect> from Zagros Mountains 01 removes the corruption and I can notice some effect (at least fog). Errors are printed.

[kosmo]

Though I don't know how the particle system works atm, I thought this might be interesting:
http://www.cs.cornel.../~tedkim/WTURB/