TrueCombat
http://truecombat.net/forums/

D's screenshot dump
http://truecombat.net/forums/viewtopic.php?f=8&t=2116
Page 5 of 6

Author:  Damien [ Thu Mar 03, 2011 10:21 pm ]
Post subject: 

Container from a few pages back, now with LOD (still a WiP):

Image

Four models are used for the cargo container sides, each having 3 levels of LOD which you can see in the image above. The transition between these models is practically seamless.

Some r_speeds screenshots for comparison, also, notice the detail loss at a distance, total transformation is from +1000 polygons for the detailed version and ~50 for the one with least polygons.

Image

Image

Ambient occlusion is baked in the model texture which makes it look less flat in-game (no lightmaps can be baked on dynamic models). I will create a common shader which will be used for clipping and casting a shadow on the map geometry.

This method allows detailed models with little performance impact.

Author:  Piney [ Fri Mar 04, 2011 12:14 am ]
Post subject: 

this is seriously awesome, i love when people fiddle with the inner tweaks! Have you needed access to the other engine's advanced functions or is this still with the "old W:ET"?

Author:  merlin1991 [ Fri Mar 04, 2011 8:58 am ]
Post subject: 

Piney wrote:
this is seriously awesome, i love when people fiddle with the inner tweaks! Have you needed access to the other engine's advanced functions or is this still with the "old W:ET"?


afaik that's "old W:ET" with misc_gamemodel and proper named md3 files

Author:  Damien [ Sat Mar 05, 2011 8:59 pm ]
Post subject: 

Right, It's an old feature, probably from Q3.

The filename structure is:

model.md3
model_1.md3 (less polygons)
model_2.md3 (even less polygons)
...

Doesn't work with .ase models unfortunately.

You place the model.md3 on a map as a "misc_gamemodel" like Merlin said and the engine does the switching automatically.


I'm not sure if it has been used in IdTech3 games, could be useful for improving the graphics if anyone's interested at all.

Author:  RedRuM [ Sat Mar 05, 2011 10:45 pm ]
Post subject: 

Damien wrote:
Right, It's an old feature, probably from Q3.

The filename structure is:

model.md3
model_1.md3 (less polygons)
model_2.md3 (even less polygons)
...

Doesn't work with .ase models unfortunately.

You place the model.md3 on a map as a "misc_gamemodel" like Merlin said and the engine does the switching automatically.


I'm not sure if it has been used in IdTech3 games, could be useful for improving the graphics if anyone's interested at all.


Being used in quake 3 itself, noticed while playing 3rd person gun skins. Each model has 3 LOD's if i remember right (LOD1 detailed, LOD3 lowest details)

Author:  merlin1991 [ Sun Mar 06, 2011 12:59 am ]
Post subject: 

If I remember correctly it was planned to have lod weapons in 0.49 but that got dropped due to time issues :?

Author:  Damien [ Sun Mar 13, 2011 6:53 pm ]
Post subject: 

So, I've been trying to render HD lightmaps in q3map2 without success. The process takes too long and you may not get good results in the end.

Blender can bake shadows on models so I decided to test it with TC:E.

The simplest method I could come up with was:
-exporting a map to .ase format
-removing unneeded faces and unwrapping it (lightmaps need unique UV's)
-reimporting it in Radiant over the original geometry

Here are some images of the last steps of the process:

.ase model with baked shadows on the left, original map on the right:
Image

.ase model placed directly over the original geometry (notice the z-fighting):
Image

Shader used for the model:
Code:
textures/ddtest/testl
{
   surfaceparm nonsolid
   polygonOffset
   qer_trans 0.5
   qer_editorimage models/ddtest/testl.jpg

   {
      map models/ddtest/testl.jpg
      rgbGen identity
      blendFunc GL_DST_COLOR GL_ZERO
   }

}


polygonOffset makes the shaded surface drawn after the base one so there's no z-fighting in-game.
blendFunc Gl_DST_COLOR GL_ZERO blends the shaded surface like a lightmap on top of the base surface


Here are some comparison shots (better Q3map2 light compile vs. my method):

Bars (q3map2):
Image

Bars (.ase method):
Image

Corner (q3map2):
Image

Corner (.ase):
Image

Crates (q3map2):
Image

Crates (.ase):
Image


Couple more shots:
Image

Image


I know my shadows are faint in comparison, still working on finding the best contrast. Also, some radiosity (bounce) and perhaps bump maps would be nice.
Surfaces in-game shouldn't be lighted but lightgrid should still be calculated for dynamic models.

In the end, this method requires more work but the results are rewarding.

If you're wondering about the size impact, Northport has 60 lightmaps at the size of 11MB. That's because the default lightmaps are .tga. weighing ~200KB at 256x256. I can make 1024x1024 lightmaps (like the example above) at 20-40KB's. That is a lot of room for HD shadows.

Don't worry about the compression artefacts, since they're blended on detailed textures, none are visible in-game.

Author:  Baal [ Sun Mar 13, 2011 7:13 pm ]
Post subject: 

Wow! Big difference to me. Nice job. Would love to play the stock maps under that.

Author:  RedRuM [ Sun Mar 13, 2011 7:13 pm ]
Post subject: 

hmm i dont see much different from stock TCE maps objects shadows, but i like the darker shadows of q3map2.

Someone enlighten me more.

Author:  Damien [ Sun Mar 13, 2011 8:23 pm ]
Post subject: 

Quote:
I don't see much different from stock TC:E maps objects shadows
I thought the images are pretty self-explanatory, q3map2 shadows = pixelated blobs, Blender export = a sharp shadow.

Quote:
I like the darker shadows of q3map2

The darker shadows are a matter of tweaking the sun/object material settings in Blender, not a problem. Either that or adjusting the texture's contrast in some image editor:

Image

Author:  RedRuM [ Sun Mar 13, 2011 9:14 pm ]
Post subject: 

well now it looks way more atracting :D

I dont know, i just didnt see huge difference between TCEs stock maps shadows and yours, maybe i just dont remember well enough.
But compared between your q3map2 picture and .ase picture it seems to be quite of an improvement.

Wish: if you do some awsum maps for CQB some day, use those darker shadows a lot, i think TCE has too few maps like that 8)

aaaand why the hell i got 5 emails regarding to this topic :shock:

Edit: Is it possible to "mix" those two techniques? Q3map2 seems to have some very dark corners and object sides but your models have very "realistic" feel in the shadows. That could do a great mix and give some nice Mood to some maps.

Author:  Damien [ Sun Mar 13, 2011 9:44 pm ]
Post subject: 

Quote:
I dont know, i just didnt see huge difference between TCEs stock maps shadows and yours, maybe i just dont remember well enough.

The shadows on stock TC:E maps are done right so pixelation is not that noticeable. They are low contrast with filtered edges.

The problem with q3map2 is trying to get the most out of sharp and contrasted shadows, this is why my example wasn't the best one (low contrast).

Here's the type of shadows that aren't easily done with q3map2 (never mind the games):
Example 1
Example 2
Example 3

One more discovery is that I can easily use 80KB 2048x2048 JPEGs (JPEG quality of ~45). Lightmaps are mostly solid colours which can help compress the image without visible artefacts.

Quote:
Is it possible to "mix" those two techniques? Q3map2 seems to have some very dark corners and object sides but your models have very "realistic" feel in the shadows.
Like I said, this is not a problem.

Author:  Piney [ Mon Mar 14, 2011 12:27 am ]
Post subject: 

Well, you never cease to amaze me! Those shadows are very nice, and the way you implemented them is quite ingenious!

From my understand, however, unless a mix of both techniques is used, dynamic objects (and thus player models) will not come under shadow rendered this way, is that correct?

Author:  Damien [ Mon Mar 14, 2011 5:40 am ]
Post subject: 

Thanks!

Quote:
From my understand, however, unless a mix of both techniques is used, dynamic objects (and thus player models) will not come under shadow rendered this way, is that correct?
That's right, I still need q3map2's light stage to render the lightgrid which affects the dynamic models. I'll just leave out the lightmap generation.

One of the things on my to-do list is find the correlation between q3map2's and Blender light parameters. So a lamp placed in Blender seems to cast the same amount of light on the geometry as the light in Radiant casts on the dynamic models.

Dynamic models = player models, weapons, 1st person arms & moving objects such as doors

The cargo container mentioned earlier would also fall in this category since it is implemented as a misc_gamemodel but using this method I can bake proper lightmaps on it which will be seen on the LOD versions as well as long as each model has it's own unique UV maps.
Yeah, this means a unique texture per model so maybe I'll have to compromise with model's texture resolution and placement.

Once I get this to work as I want to I'll post a guide.

Author:  coroner [ Mon Mar 14, 2011 6:42 am ]
Post subject: 

I think the comparison is a bit unfair.

You can also use a much higher lightmap resolution in q3map2 (TCE uses 4 pixels, CQB probably 3, if wanted one can use 2 or 1) and save it at any tex format you want, e.g. 1024 * 1024. It is also possible to compress external lightmaps afterwards, e.g, jpg. This would, of course, only keep the distribution package small, it doesn't matter in game.

Also, artifatcs are not expected in TCE or CQB since they use no overbrightbits which caused problems in the original Q3 series, leaving only 6 bits for colors and pushing compression artifacts.

In the end, the lightmap resolution is pretty much a decision about texture memory. CQBs sample map currently has 25 512*512 lightmaps with a resolution of 3 pixels, which is slightly better than TCE. I don't know how the minimum system spec would respond to something like 60 1024*1024 lightmaps for single pixel lightmap resolution.

I very much like the door mechanic on the containers and this is really needed. Due to the lighting problems with gamemodels I would let the container body be static with reasonable details (misc_model) and let the mechanics only be a lod model.

Page 5 of 6 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/