Messages

16

Artwork / Re: Normalmaps Updates [THEY FINALLY DID IT !!!]

« on: April 28, 2010, 02:04:42 pm »

Have patience; this is still a work-in-progress.  Could you post some of the normalmaps you're having problems with (eg. skins, heads) so I can use them for testing?

17

Artwork / Re: New Feature: "Glow" textures

« on: April 28, 2010, 01:30:19 am »

Glow should no longer be visible through other models as of r29626; let me know if there are other issues.  (NOTE: current SVN (r29626) seems to hang on the loading screen; I think this has something to do with recent changes in the file-system drivers.)

18

Artwork / Re: Normalmaps Updates [THEY FINALLY DID IT !!!]

« on: April 27, 2010, 02:42:53 pm »

First off, I just want to point out that the code is still a work in progress, and shouldn't be considered representative of what to expect yet.  That said, the normalmaps for the geoscape and the normalmaps for the battlescape are not actually handled the same way.  The reason for this is that the geoscape uses orthographic projection, and the battlescape uses perspective projection.  The alpha channel of the geoscape normal maps is actually used to specify specular reflectiveness; the alpha channel of the battlescape normal maps is used to specify height (for parallax, which is meaningless for orthographic projections).

There are also some issues with the models; all the normal vectors for the verticies of the earth on the geoscape are correct, and nicely smoothed.  It's easy to get them right, because it's a sphere.  For the arbitrary meshes in the battlescape, there are places where two triangles share a vertex (in the actual .md2 file) but where smoothed normals look very strange.  This results in surfaces where the mesh looks flat but the normals look curved; while this is nice for smoothing things that *should* be curved, it looks strange when applied to sharp corners.  I'm planning on writing some code to attempt to de-construct and re-construct models to fix this, but haven't done so yet.

Another issue is that the light sources are generally not in locations that make any sense.  This is because up until now they never had any effect on the actual appearance of things.  The lighting system is going to need some work before things will really start to look good.

Finally, load-times in the latest build are long; this should be fixed soon.  Right now all the normal and tangent vectors are being calculated at runtime, but Mattn is working on a tool to compute them off-line and store them in data files.  Once he's done, load times should go back to the way they were before.

19

Artwork / Re: New Feature: "Glow" textures

« on: April 25, 2010, 09:39:29 pm »

For the most part, yes.  In the places where we have animated textures now, you can use animated glow-maps.  I think the issue is more that currently you can only have animations associated with materials, which means things like soldiers, aliens, weapons, dropships, etc. can't have animated textures (with or without glow).  Mattn and I are in the process of trying to make the rendering system more uniform so that there are fewer things than only work for certain types of objects, but it's a fairly major project, so I expect it will take some time before we really get everything the way we want it.

20

Artwork / Re: New Feature: "Glow" textures

« on: April 25, 2010, 06:36:29 pm »

Man, it's a good thing the aliens don't really understand the concept of a "sniper"...

21

Artwork / Re: New Feature: "Glow" textures

« on: April 24, 2010, 08:34:11 pm »

@geever, I thought we had done that; there are already separate menu options for GLSL and postprocessing.  If you disable post-processing, it shouldn't use any framebuffers.  Can you tell me what, exactly, breaks on your system so I can try to fix this?  Actually, go ahead and open a bug in the bugtracker for this and assign it to me, and put your info there. 

22

Artwork / Re: Normalmaps Updates

« on: April 24, 2010, 08:23:24 pm »

I'm working on it, but don't hold your breath while you wait

It's going to require a more major overhaul of the current rendering system to get this incorporated than the previous changes I've made.  The major difficulty is that I don't want to change the way that existing content looks, or require any existing content to be re-created in some new format.  The glow-textures were strictly an "add-on," but there's already code that handles bumpmapping for brushes, and it doesn't work in a way that can be directly applied to meshes (as it requires several extra textures that, so far as I can tell, get built with the map at map-compile-time).  That means I need to be very careful in the way that I handle things so I don't break existing content.  If I didn't care about preserving backwards-compatibility, it would be easy, but that's really not an option here, for all the obvious reasons.  So be patient; I'm confident I'll eventually figure out a way to do this that won't break anything, but it will take time because I need to be sure I fully understand how everything is working now in order to be sure I don't alter the way it looks to the user even if I'm changing the way it works behind the scenes.

23

Artwork / Re: New Feature: "Glow" textures

« on: April 24, 2010, 08:13:52 pm »

For the record, I can basically eliminate the flicker (and improve the overall smoothness of the glow to boot), but there's a performance cost to doing so.  On my system, the framerate drops from 60fps to 30fps when I use the flicker-free version (due to vsync, there isn't any middle ground, so that's not actually quite as bad as it sounds; it just means that it crossed below the threshold at 60fps).  I've attached a patch if you want to try it, but I'm not sure we want to put it into the SVN because of the performance issues.  We could add an option to the graphics menu that let the user select what level of glow-smoothness they wanted (ie. low, med, high) or something, if people think it's appropriate, at which point I would be more comfortable including the patch, since it would effectively be optional anyway.

24

Artwork / Re: New Feature: "Glow" textures

« on: April 23, 2010, 01:54:33 am »

I'm getting some brushes that glow and some that don't in the latest version, though you and I have been messing with a lot of the same stuff in our parallel efforts to fix the same problems, so I'm not confident that the issue isn't on my end.  Out of curiosity, what did the issue turn out to be?  That way I can be aware of it in the future.

25

Artwork / Re: New Feature: "Glow" textures

« on: April 21, 2010, 04:02:36 am »

Personally, I think that some of those textures may still be too bright, while others are looking good.  The "seats" looks like a nice subtle effect from the screenshot; the ship exteriors are probably still a bit too bright (the fighter in particular).  The issue is not so much what the maximum intensity is, but that the intensity is so uniform across the ship.  I think it would be more interesting to have, for example, the engines be fairly bright, with the rest of the green parts having a more subtle, dull glow; maybe weapons could be intermediate, or something.  But this is all really just a matter of aesthetics and personal opinion.  As you said, anyone can edit the textures to change brightness, distribution, etc.  In fact, I may poke at some of the textures myself at some point; just not tonight.

26

Artwork / Re: New Feature: "Glow" textures

« on: April 20, 2010, 07:10:30 pm »

Color-mapped PPMs work fine for me (your new scout-glowmaps work just fine).

27

Artwork / Re: New Feature: "Glow" textures

« on: April 20, 2010, 06:26:39 pm »

BTAxis is right, there's no need for an alpha channel for the glowmaps.  MCR, it's possible that the alpha channel is the reason that you thought that the color intensity didn't matter.  If you're using the alpha channel to change the "intensity," then the actual color values of the pixels haven't been changed at all, which is why it doesn't look any different in game.  If you just work in RGB (instead of RGBA), you won't have that problem. 

28

Artwork / Re: New Feature: "Glow" textures

« on: April 20, 2010, 04:55:05 pm »

Actually, the brightness of your texture *will* affect the brightness of the glow.  As an example, take the following two screenshots; the only difference was which version of the plasrifle_gm texture was used.  As you can clearly see, the glow is brighter in the second screenshot, due to the fact that the colors in the glowmap are brighter in the second version of the texture.

It should still generally be possible to reduce the colorspace, given that the majority of models shouldn't have that many different colors of glow (Mattn's computer aside).  If you're using PNGs, there are even automated tools that will do the colormap for you (eg. pngrewrite).

29

Artwork / Re: New Feature: "Glow" textures

« on: April 19, 2010, 10:31:32 pm »

Yes, I did revert those changes because they were preventing the loading of other types of glow-map images that we wanted.  Also, as I recall, the way it was written it didn't actually load glowmaps for it_world images, either (because it was an "else if" clause after one that had checked for it_world).  At the moment, I don't see the harm in testing for glowmaps for all images; we might want them eventually.  If you'd like to add some restrictions back in, we can do so.

And your logfile seems normal as far as i can tell, which means I'm still stumped by your magical-rainbow glow.

30

Artwork / Re: New Feature: "Glow" textures

« on: April 19, 2010, 07:53:24 pm »

Mattn,

Try applying this patch, and then post the output for me.  I'm thinking that maybe somehow the glowmap pointers that should be NULL are winding up pointing to arbitrary memory on your system; that would account for everything being glowy (since the pointer is used to check if a glow texture exists), and it would also account for the rainbow-colors (since the contents of that memory segment would be arbitrary).  I'm not sure exactly how that's even possible, but that would be my best guess at a cause.   Actually, why don't you post your copy of r_image.c while you're at it, just so I can make sure nothing odd is going on.