How to make DP render flat-shaded?

[Urre]

Not exactly a QC question, but I guess this forum is the most fitting. Does anyone know how I would make DP render models flat-shaded?

[Supa]

Did you try r_showsurfaces 3 yet? Other than that I've had to resort to 4x4 solid colour skins, so I'd be interested in hearing a proper way to do this too. :)

[leileilol]

I think he means non-normal lighting stuff. I'd suggest just tearing apart the default.glsl after dumping it, and get rid of attenuation ramps in the lighting. This will screw up map lighting if you use rtworld

[Urre]

Supa: I take it you mean making stuff single-colored? I already do that the same way you do . There is however a proper way to do this, DP got support for vertex colors per mesh in q3shaders some while ago, haven't tested it.

leileilol: Screws up how? I'd like to keep realtime lights. Also, care to post an example default.glsl?

On a separate note, is there a way to dynamicly change which *.glsl file is used, like a stuffcmd or something?

[leileilol]

I already do that the same way you do

you could go further with colormod abuse or even scripts/ .shader, with map $whiteimage and rgbGen const to save even more texture memory

I wouldn't recommend uploading a glsl file as an 'example' since revisions of DP could render it obsolete. There is a command in DP that dumps it though.

[Urre]

I wouldn't recommend uploading a glsl file as an 'example' since revisions of DP could render it obsolete.

That has always been and always will be the case with DP, but it'd be better than nothing, if you know what needs to be changed. I haven't touched GLSL yet, so I wouldn't know where to start.

[Supa]

leilei; Thanks. :)

On a separate note, is there a way to dynamicly change which *.glsl file is used, like a stuffcmd or something?

Right now all you can do is reload the defaults. I've talked with LH about it before and he has expressed an interest in seperating everything into multiple scripts and providing a means to load new scripts on the fly, but given what he's working on at the moment there's no telling when he'd be able to do that.

[Urre]

I can't get this working. Anyone GLSL proficient want to give it a shot? I'd actually want this to be a cvar, and not bound to GLSL only :S

[Sajt]

I'm not sure what you want. If you're looking for "faceted" lighting, I don't know if it's possible without modifying the engine, since you need the triangle normals. Probably the best idea is just to process your models, splitting all vertices up so you have 3x more vertices than triangles.

[Urre]

That'd do it. Any simple way to do it with QME? :S

[Sajt]

If you are only concerned with MDLs, then I will get right on the "MDL tool" that someone else wanted for fixing texturemapping. This could be a simple feature added to that tool.

Actually, If I recall, QWalk can do this with the "-facetize" argument. But it would involve importing MDL then exporting MDL, which is not recommended using that tool. You could still try it as a test though.

[Urre]

I am only concerned with MDL's yes. I will try that, thanks!

[mh]

Now I'm confused too. Unless I'm reading things very wrong, isn't this the same as what gl_smoothmodels 0 does?

[Urre]

mh: Sounds like it, except DP doesn't have such a cvar. Do other Quake engines have it?

And how can flat-shaded be confusing? That's what it's called in every modeling software out there. I want to disable the smoothing, yes.

[mh]

Most GLQuake-derived engines should still have it, it's just the lines:

Code: Select all

   if (gl_smoothmodels.value)
      glShadeModel (GL_SMOOTH);

in R_DrawAliasModel.

FitzQuake definitely has it, and it should be there in DirectQ too (although it's not a lighting mode I test too often so I can't confirm it works). I'd be shocked if ProQuake didn't have it, and I don't really know about other engines, but it's in ID's code so unless the author removed it it should still be there.

Maybe LH removed it from DP for some reason?

I'm not certain that it would be possible to implement this in a shader as the color values for each vertex would require knowledge of the values for other vertexes, as well as knowledge of when each primitive begins and ends. That's far beyond the remit of a vertex shader (and not even relevant for a fragment/pixel shader).

A shader is definitely overkill for this kind of thing anyway; I'd say petition LH to reinstate it instead.