Lighting
Re: Lighting
Yes, the landscape has always had gouraud shading (one of its key features when it was released) and therefore I was wondering why the models didn't...
Of course it would be good to be able to disable it, since most current models wouldn't look very good with it.
About smoothing groups, they don't need to be separately supported since they simply work by splitting the mesh and using duplicate vertices.
Of course it would be good to be able to disable it, since most current models wouldn't look very good with it.
About smoothing groups, they don't need to be separately supported since they simply work by splitting the mesh and using duplicate vertices.
-insert deep philosophical statement here-
Re: Lighting
Agreed. it will be good if we could switch them on/off in debug menu for a test purpose only.Jorzi wrote:Of course it would be good to be able to disable it, since most current models wouldn't look very good with it.
Re: Lighting
Hmm I don't know why they would be needed in debug mode, I just meant that old models should probably be rendered as they are, while new models would be smoothed with sharp edges pre-defined by splitting the mesh (smoothing groups).MaNGusT wrote:Agreed. it will be good if we could switch them on/off in debug menu for a test purpose only.
-insert deep philosophical statement here-
Re: Lighting
I meant that till the new models aren't completed, there is no need to write a double code for the old and new models.Jorzi wrote:Hmm I don't know why they would be needed in debug mode, I just meant that old models should probably be rendered as they are, while new models would be smoothed with sharp edges pre-defined by splitting the mesh (smoothing groups).
We can test a new models by pressing "on" button in debug menu and when they all will be completed then smoothing could be set statically "on".
Re: Lighting
Ok, but that would make it impossible to use unsmoothed models, which could be useful for some buildings etc, which is why I'd prefer to simply have the gouraud flag back...
-insert deep philosophical statement here-
Re: Lighting
yep.. it would be awesome..Jorzi wrote:Ok, but that would make it impossible to use unsmoothed models, which could be useful for some buildings etc, which is why I'd prefer to simply have the gouraud flag back...
Re: Lighting
I disagree, vertex normals should be incorporated into the model format, this way we can have the model editor do all the heavy lifting, and the same normals that are used in the editor are used in game (this matters for tangent space normal mapping).Per wrote:The normals are calculated in a very naive manner. This should be improved one day. I think the right place to do this is in the C++ code.
Btw, gouraud shading is turned on, but like per said, the normals are specified in such a way that it is the same as if it used flat shading.
Re: Lighting
I see....
Having the normals integrated into the .pie format sounds sensible, keeping the game code a bit simpler.
On the other hand, it breaks backward compatibility and makes the .pie format a bit cluttered, especially since we probably want it to store the tangents (and binormals) as well...
This is the reason I prefer object space normal maps, despite taking up lots of texture space
Having the normals integrated into the .pie format sounds sensible, keeping the game code a bit simpler.
On the other hand, it breaks backward compatibility and makes the .pie format a bit cluttered, especially since we probably want it to store the tangents (and binormals) as well...
This is the reason I prefer object space normal maps, despite taking up lots of texture space
-insert deep philosophical statement here-
Re: Lighting
Oh, if we can get the model editor to do that job for us, I'm all for that. </lazy>Safety0ff wrote:I disagree, vertex normals should be incorporated into the model format, this way we can have the model editor do all the heavy lifting, and the same normals that are used in the editor are used in game (this matters for tangent space normal mapping).
Re: Lighting
I'm not too worried about this, I'm thinking whole new format, scrap backwards compatibility.Jorzi wrote:On the other hand, it breaks backward compatibility and makes the .pie format a bit cluttered
Re: Lighting
Ah yes.. after all, you know what you're doing while I'm still learning syntax and stuff...
-insert deep philosophical statement here-
- milo christiansen
- Regular
- Posts: 749
- Joined: 02 Jun 2009, 21:23
- Location: Perrinton Michigan
Re: Lighting
Kind of like resurrecting the WZM format?
In general, if you see glowing, pulsating things in the game, you should click on them.
- Demigod Game Ganual
- Demigod Game Ganual
Re: Lighting
If by resurrection you mean something completely different with the same extension, then yes.milo christiansen wrote:Kind of like resurrecting the WZM format?
Re: Lighting
I was about to request an additional specmap texture for use in the fragment shader, but since we apparently need a new file format anyway, I guess the implementation can wait...
However, a question about lighting, why is the main light currently a point light and not a directional light?
Instead of having a constant direction vector for the light, it seems to have a specified position and the light vector is calculated for each vertex by subtracting the vertex coordinates from the light coordinates...
However, a question about lighting, why is the main light currently a point light and not a directional light?
Instead of having a constant direction vector for the light, it seems to have a specified position and the light vector is calculated for each vertex by subtracting the vertex coordinates from the light coordinates...
-insert deep philosophical statement here-
Re: Lighting
did you say about the specular color texture?Jorzi wrote:I was about to request an additional specmap texture for use in the fragment shader, but since we apparently need a new file format anyway, I guess the implementation can wait...