Smooth shaded vertex-lit shader - how?

(G0-Gerbil) #1

I’m sticking in little ASEs of things as misc_models, and I want them to be vertex-lit and to have smooth lighting. Erm… how? :slight_smile:
So far it’s vertex lit, but with flat shading which just looks pants, really.
Here’s a test shader so far:

textures/mml_helmsdeep_b1/shroom_under
{
	q3map_nonplanar
	q3map_shadeAngle 45

	surfaceparm nolightmap
	surfaceparm pointlight
	{
		map textures/mml_helmsdeep_b1/shroom_under.tga
		blendfunc GL_ONE GL_ZERO
		alphagen identity
		rgbgen vertex		
	}
}

What be I doin’ wrong?

(Davros) #2

hmm, increase the shadeangle to 89 perhaps

(Ifurita) #3

Do you have a pic of the current results and a description of what you want it to look like?

(G0-Gerbil) #4

Hmm I upped the angle to 150 - no joy. I’m clearly missing something. Been so damn long since I used vertex lighting!
BTW I’m using the radiant compile line of:

Q3Map2: (final) BSP -meta, -vis, -light, -fast, -filter -samples 2

Here’s the end results:



I think I’ll just set 'em to use lightmaps and be done with the darned things. Just thought I’d try to help the poor little game engine where I could, and this is the thanks it gives me!

Guess I’ll also have to up the side counts, I ended up making the little munchkins bigger than originally planned so the low polygon count is a touch harsh.

(Detoeni) #5

remove filter, its working against samples (filter blur, samples sharpens)

What compile options did you use to make the ase?

ASE are vertex lit when theres no spawn flag 4(or is it 2…erm…) or no shader found.

(G0-Gerbil) #6

ASE are vertex lit when theres no spawn flag 4(or is it 2…erm…) or no shader found.

Really? Ahhah! That would be cool if true - off to test :slight_smile: Lightmapping isn’t so hot - the polygons on the shrooms are so tiny that they come out very bland.

So what’s a decent final compile option? I’ve never got into compile lines TBH, just always stuck with what radiant offers.

(G0-Gerbil) #7

Of course me saying I’ve never got into compile lines is a complete load of tosh, since I got brave one day and set up my ASE export line, which is:

<key name=“bsp_Q3Map2: (convert to ASE) BSP -meta -convert” value="! “C:/Program Files/GtkRadiant-1.4/q3map2” -v # -game et -fs_basepath “C:/Games/Enemy Territory - Mapping/” -meta -mv 1024 -mi 6144 $ && ! “C:/Program Files/GtkRadiant-1.4/q3map2” -v # -game et -fs_basepath “C:/Games/Enemy Territory - Mapping/” -convert format ase $"/>

Is the complete line I stuck in my .PROJ file.

(G0-Gerbil) #8

Harumph it still does it with flat shading, but I do think it looks a bit better than the weird lightmapping artifacts.
Hmmm this reminds me of my days messing with vertex lighting in RTCW - wasn’t there a way of creating a shader such that q3map2 would see it during compile, but ET wouldn’t see it during the game?
Something like sticking :q3map at the end of the shader name definition.
Time to go search :slight_smile:

(G0-Gerbil) #9

Bah can’t get it to work, but I think this may be because the ASE isn’t being treated as a group of connected triangles but as individual ones.
I dunno really, it’s late and I can’t be arsed to spend more time on the 'shrooms right now - possibly this method just won’t work with ASEs.

I may have a go over the ASE files manually to see if there’s a smoothing option within them. Darned things…

(Detoeni) #10

Your compile options are ok for the map apart from “filter”, “samples 3” maybe for final compile (on a map that big it might have adverse effect on compile time, don’t bother if your using large lightmapscale).

Your ase compile tells me you made the 'rooms out of brushes. Ooops. Q3map2 will base the smooth groups on the texture projection. This is giving you about 10 or so smooth groups on each 'room. If you had made them from smp’s, collapsed down to single and dubbel poly’s, which are then welded with bobs tools and set the textures using “cap”. This would mean all the curves are welded, and the texture is projected from one direction. This would give you the three smooth groups that you need and make them light right.

You can edit the ase to change the mesh smoothing, but you’ll still have the problem of too many groups.

(G0-Gerbil) #11

I did think it might be something like that initially - indeed the original 'shrooms use two textures that are projected in the Z direction, so their texture UVs must align.
My process was to create the first stage ASEs from brushes using the Z projection shaders, then manually edit (search / replace stylee) these shaders in the ASE (using a text editor) to point to identical but not Z projected textures, on the basis that the UVs were by now baked into the ASE so I could simply work from them.
Then I used these modified ASEs to build other ASEs which are actually what goes into the map.

I’ll take a quick look at the smoothing groups in the ASE, and if I don’t see anything obvious, I’ll have a bash at using patches.

Cheers Det - btw nice models in your other thread :wink:

(G0-Gerbil) #12

Um errr… If I just have the patch-based shroom in a pure caulk room, the shroom polygons don’t actually compile in (although I get the shader references).
I assume my ASE compile option is missing something to do the patch conversion? :frowning:

(CooperHawkes) #13

add
-patchmeta -subdivisions 4
to the bsp process…
replace 4 by lower numbers for more subdivisions (more polys) and vice versa

EDIT: did you try to func_group the brushes? maybe it does the job too and you don’t need to use patch meshes

(carnage) #14

go gerbil have you considered using the LOD modeling for the mushrooms to get realy nice close up ones

(G0-Gerbil) #15

Cooperhawkes - cheers, will try :slight_smile:

carnage - not reallly, although I’ve had the LOD stuff in mind for a variety of other things (mostly trees / foliage to correct the mess that is stuff like Radar!). I still haven’t sat down and worked out how to convert ASEs to MD3, which is the sticking point on that process.

(Detoeni) #16

-patchmeta, yes you need this, I thought after posting that I should have said, oops.

-subdivisions 4(default is 8 ), no point, if hes made them like i sergested thet wont be afected by this.

LOD models need to be used as run time entities, not practical for this use.

(CooperHawkes) #17

Usually I use q3data to build a first version of the md3 and then I fix errors / set tags using Nferno`s MD3Compile utility.

Detoeni: afaik using subdivisions will result in changing the refinement of the (curved) patchmesh whereat the level of refinement depends on the pm curvature… but maybe I didn’t get your point. :frowning:

(G0-Gerbil) #18

I’m pretty sure that Det’s understanding of how the export to ASE with patches works is the same as mine - it doesn’t do dynamic subdivision like wot you see in-game, but applies a fixed supdivision regardless throughout to all patches.
Not that I mind, for a static model, I prefer this kind of direct control 'cos then you know exactly what you end up with.
Mind you it should really be matched in radiant by the ability to specify a certain subdivision on the patches, as well as it’s dynamic current method - then you could know exactly what you were getting.

I’ll have a look at that ASE to MD3 thing hopefully in the next few weeks once HD is out of the way, I know I could use LOD in MT, and I certainly want it for Church if we aim to have a proper forest-type scenario :slight_smile:

(Detoeni) #19

Patches in the Q3 engine are based on splines. for a spline to work it needs two reference points and a control point, subdivisions can be calculated along the path of spline. When you collapse a simple patch mesh down to a single poly, you no longer have a working spline, because you only have two points of reference and no control point. So no subdivisions can be made…

If the mushroom had been made in a way affect by subdivisions then a setting of 4 would result in gerbils mushrooms each been made up from 160 polys instead of 36, ummm thats a little high don’t you think?

(CooperHawkes) #20

k, now I got it :wink: I wasn’t aware that you already broke the patches down into flat faces…

I know, 4 is a little bit too low sometimes… depends on what you want to achieve… I like beautiful, round mushrooms :stuck_out_tongue_winking_eye: However 160 polys is too much for such a small detail, you are right… even 36 seems to be a little bit high… 10 tris for the trunk and 18 or 20 for the cap should be ok… IMHO the cap does not need to have a bottom side… you won’t see it anyway :wink: