Sparklies in brushes definately aligned?

(G0-Gerbil) #1

I’ve written my own editor to import spline-based shapes into radient.
It works fine, except that the results feature sparklies - even though before I export all my values I am clamping each brush face definition points to integers (I’ve tried clamping to x2 grid, x4 grid as well - the brushes are obviously more likely to be distorted, but still show the sparklies).

Some of these are super-sparklies though - the term I use to describe faces that have had new vertices added along a seam so you end up with a much larger gap.

All my sections of splines are grouped, and the shader applied to them (it’s just one for testing purposes) uses the following script:

// Track texture (used to find when merging pk3 data back into my own)
textures/mml_racey/track
{
	q3map_nonplanar
	q3map_shadeAngle 25	

	{
		map $lightmap
		rgbGen identity
	}
	{
		map textures/mml_racey/track.tga
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

Basically I want lightmapped phong shading.
I’m using the following compile line:

! E:/PROGRA~1/GTKRAD~1.11/q3map2 -v # -game wolf -meta $ && ! E:/PROGRA~1/GTKRAD~1.11/q3map2 -v # -game wolf -light -fast -filter -super 2 $

which is basically the normal final compile, but without bothering with the -vis stage (all my brushes are detail, with a single structural hollow cube surrounding everything). I can use the various other compile options too (including -vis), it’s purely for speed of compiling I’ve removed some of the options).

I’m using 2.3.32 (the one that shipped with radiant 1.2.11).

All brushes generated by my code are valid, and clamped to integer points, so I can’t understand why they are getting jiggled around during compile.

Any ideas gratefully accepted.

(digibob) #2

Any chance of a screenshot? :wink:

(G0-Gerbil) #3

For you, anything :drink:

Here’s two of the supersparklies. I appear to have misinformed myself about new vertices being added though - it’s actually that one of the vertices doesn’t match up with the surrounding ones. BTW these screenshots were taken using the latest version of q3map2, which I just updated to test.


And here’s an overview of my output:

(digibob) #4

How about s slightly less zoomed in shot, but still close enough to see detail? :wink:

(G0-Gerbil) #5

Well, the top pic should be clear enough.
The vertex that should be in the same place as where the rest meet is slightly down and too the right of the main vertex.
These are all exported as the same location, although each face is technically a seperate brush (each face is made into a brush by creating three other faces behind it to make a triangle-base pyramid - the other faces have nodrawnonsolid on 'em).

Oddly enough, just tried a compile using q3map, and I still get them. Less of them, but still around.

What is wrong with having a brush where all vertices are aligned to the grid? sobs

(ydnar) #6

OK.

Don’t bother with brushes like this, you’re only setting yourself up for a headache.

Just write a spline->ASE converter and place the track as a misc_model entity and let Q3Map2 do the clipping via q3map_clipmodel in the shader.

That way you can have perfectly imported, UV-mapped, clipped track geometry with a minimum of hassle.

Or alternatively, download the source and add a PicoModel module to read your spline model format so that GtkRadiant + Q3Map2 can support it natively.

y

(G0-Gerbil) #7

Cheers, kinda :wink:

OK, time to write a convertor for my convertor to exporter to .map format :wink:

Is .ASE a standard in itself, or is it like old max formats, IE a million permutations which don’t usually appear to be interchangable?

Just want to make sure I export to the correct format!

Bah, and I just went to the effort of uploading the source for others to take a look at! Oh well, no point looking here now then, eh?

(ydnar) #8

No, don’t bother with .map format. Brushes are not suitable for this kind of geometry.

ASE is a nice, clean text format that is well documented, stable, and supports per-vertex XYZ, normal, and ST coordinates. GtkRadiant and Q3Map2 both have full support for most ASE features (except smoothing groups or > 1 UV per vertex, which shouldn’t pose a problem if you’re creating the exporter).

See here for a decent description of the ASE file format.

y

(G0-Gerbil) #9

Thanks for the info, I can see what I’ll be up to tonight :wink: Also on a related note, should I try to keep my vertices in .ASE format rounded to integer values or are any floating values ok?

Just out of curiosity, under what circumstances will brushes not really be suitable? Only the more I map, the more I seem to run into these weird super sparklies.

(G0-Gerbil) #10

Sorry to be a pain, but any pointers to a working ASE file I can use as an example would be kinda cool :smiley:
Only the ones I’ve downloaded don’t actually seem to work :eek2:

(ydnar) #11

There is an example map here with a working ASE file, courtesy of Willi Hammes.

y

(G0-Gerbil) #12

Muchos gracias.

djbob also pointed me in the direction of a certian little -convert switch in some q3map2 program someone or other made, which I’ve happily played with.

Is there anything q3map2 doesn’t do? :eek2: :slight_smile:

Many thanks again.

(G0-Gerbil) #13

OK, I’ve got it mostly working, only left to export are the face and vertex normals correctly (currently they default to up, hence the rather bad lighting on the track itself!).

Once again thanks for your help guys - although it’s been a bit more work than I’d originally intended, this way is vastly more flexible so I’ve come out ahead of the game cheers to ydnar and djbob :clap:

(ydnar) #14

Note if you want the model to be lightmapped, add the following to the shader:

q3map_nonplanar
q3map_forceMeta

And make sure it has texture/lightmap stages.

If you want it to be solid, add this:

q3map_clipModel

y

(G0-Gerbil) #15

OK all sorted. Supplying the vertex normals was the key point I needed - I was getting very broken lightmaps before that.

So just to show how it all looks now (quickly knocked up):






There’s a fair few examples of the edges of lightmaps still not matching up, but they are a lot closer now than before, and it’s certainly more than acceptable (and will look a lot better when I have more interesting lighting / modelling in).

Once again, thanks for all the help :slight_smile:

(ydnar) #16

Given that your track is so well tesselated, you might consider just using vertex light…

Nice shots, BTW :slight_smile:

y

Edit: This seems kind of obvious now, but why didn’t you just make a spline to patch mesh converter? That way it can have LOD, intelligent tesselation (colinear rows removed, etc) and cleaner lightmapping?

(G0-Gerbil) #17

The patch mesh convertor is obvious, yes.
Now you mention it :smiley:

The outline that can be swept along the splines isn’t necessarily going to be so friendly for a patch mesh ultimately - although the example I have here would indeed probably work quite well.

Basically though, I rip the 3D and lightmap data from the BSP to use in my own programs - I’m not creating a racing mod for RTCW or anything like that. Sadly, due to bugs, vertex lighting doesn’t work in the software I use, and lightmaps are much more lush generally anyway (although I did a test render and must admit, with such high tesselation it is indeed more than passable, and as you point out it creates no obvious ‘joins’ in the lighting) Also for this reason, it’s simpler for me to rip the model polygons out from the BSP as-is, rather than run through my patch importer, which isn’t as good as the RTCW / Q3 one (although it’s based on it’s code!) - I only ever got around to implementing individual patches (IE it doesn’t ensure patch joins are fine, nor is it brilliant on the LOD side of things).

Basically this does what I want, looks (in most cases) great, and ultimately should be plenty flexible enough :slight_smile:

When I get a demo of my game running, I’ll post a link fingers crossed should be in a couple of days thanks to you helping me sort this!

[EDIT] Another thought - I’m using catmull-rom splines to create my patches, which I don’t think would directly translate into the erm… quadratic patches (?) RTCW uses.

(ydnar) #18

Q3Map2 has -patchmeta and -subdivisions N (default 8, use lower values for higher tesselation) to automatically tesselate patch geometry into triangle meshes.

Then again, if you can’t use vertex lighting, the result will be a wash. Might as well use your explicit spline->mesh conversion you already have.

To convert a Catmull-Rom spline to a quadratic bezier, I believe you can find the intercept point of the tangent vectors between two control points and use that as a quadratic curve midpoint.

Alternatively use a two-step process whereby convert to a cubic curve first, then approximate each cubic bezier segment with two quadratic segments.

y

(G0-Gerbil) #19

It’s not much (collision is particularly buggy - am going to redo it from scratch) but here it is so far (assumes you have shockwave 8.5 - should auto-install if you don’t):

http://www.theburrow.co.uk/wolfy/sparklies/racey.htm <- just over a meg, mostly music cos it makes such a difference :slight_smile: