#1703 posted by wakey on 2020/04/04 19:25:22
The .md3 exporter i use seems to be a 2.78 exporter retrofitted for 2.8.
Found it via a big searchmachine.
I also tried an .ase exporter, yields exactly the same results.
Your tipp with "clear custom split normals" did help somewhat:
https://imgur.com/a/TwYasgA
I also set the margin for the uv islands higher and deleted the second uvmap.
#1704 posted by chedap on 2020/04/05 06:41:06
I've imported the compiled map, and it turned out that the model gets split into parts at bsp stage. I then recompiled without the "-meta" flag and got this result. Seems alright.
I don't know what other consequences omitting "-meta" has, or if there's a more elegant solution. It seems that the problem is unrelated to UVs or model specifics though.
Never figured out how to get a good lightmap resolution, does it have to be defined per-material?
Thank You
#1705 posted by wakey on 2020/04/05 10:25:33
A very interesting discovery!
Afaik -meta is considered a "must" switch since the highdays of q3 mapping.
Regarding to q3map2 itself -meta "Combines adjacent triangles of the same texture to surfaces", which seems to improve performance because of saving triangles.
As for lightmapping models, meta also seems to be considered a must, as for example spawnflag 4 proves, which forces meta on a model.
Here is what the Radiant has to say about it:
"FORCEMETA : Toggles on q3map_forceMeta for lightmapped models. Converts model triangles to bsp metasurfaces."
Not sure if it really still is a "must", but there must be a good reason why it is still considered so, apart from saving a few hundred triangles.
There are two new switches in that latest version of q3map2 (2.5.17.n) included with NetRadiant:
-metaadequatescore <N>
Adequate score for adding triangles to meta surfaces
-metagoodscore <N>
Good score for adding triangles to meta surfaces
No clue how those are properly used though, i.e. what the baseline of that score is or should be or how it is calculated, but those could lead to the desired solution then, to get the model not as "chopped" up by -meta.
To get a good lightmap resolution, q3map2 has a few options to offer:
Per material settings (set in the .shader),
per entity settings (set via entity/func_group),
per world settings (set in the worldspawn),
and finally per general setting, via compile switches (most important here is the -samplesize switch, wich has to be set both in the bsp and light stage to work).
I always use the latter to set a higher resolution baseline and fine tweak from there.
My standard switches for the light stage are set as follows:
bsp -meta -samplesize 4
light -samplesize 4 -thresh 0.1 -deluxe -samples 4 -filter
The -fast switches just make no sense to use for me anymore, as even settings that where considered "ultra" in 2005 are just as fast to compile as testsettings back then, on nowadays machines.
#1706 posted by chedap on 2020/04/05 12:40:28
Ah, I was missing the bsp -samplesize.
A brute force workaround then is to just use "-samplesize 1". Not perfect but getting there. Would give your hardware a chance to sweat a bit, too.
Well, I'm not entirely serious, preferrably there'd be a way to keep the slivers together instead. I'll try some things, but at this point I know less than you do.
#1707 posted by wakey on 2020/04/05 17:31:36
Here -samplesize 1 didnt yield the same result:
https://imgur.com/a/83h426o
I now played around a bit more with the -metaadequatescore and -metagoodscore switches and found out that they indeed change how q3map2 breaks up the model.
Q3map2 also pointed to the source file surface_meta.c, where i found out the baseline values seem to be as follows:
DEFAULT_ADEQUATE_SCORE = 110000
DEFAULT_GOOD_SCORE = 120200
PERFECT_SCORE = 131200
Yet i have yielded no satisfying results and have no idea how to properly (ab)use those switches.
#1708 posted by chedap on 2020/04/05 20:20:04
Using "_lightmapscale" "0.25" entitiy attribute gives the same result as samplesize 1, except locally. Here's a result of a basic compile with the following:
-bsp -meta -samplesize 4
-light -samplesize 4 -samples 4 -lightmapsize 1024 -filter
I also got it to split the models less, using these:
-bsp -meta -samplesize 4 -metagoodscore 50000 -mv 30000 -mi 30000
-light -samplesize 4 -samples 4 -lightmapsize 1024 -filter
(no _lightmapscale in entity this time)
The problem is that I can't see a way to finely control this, basically it just randomly picks a direction and compares normals. Cylinders always look bad. And it seems like the very best case we can hope to achieve would just be the exact copy of compiling without "-meta".
Not sure why you couldn't get the result with "-samplesize 1". Here's the model+texture I'm using (texture reprojected from the low-res one in the .pk3).
Compiling without "-filter" noticeably improves the seams on cylinders, but makes the rest of the lighting worse.
I'm throwing in the towel for now. At least this hasn't been entirely fruitless. Maybe people with q3 experience could tell more.
#1709 posted by wakey on 2020/04/05 20:59:29
Thanks for the help, it is very much appreciated!
I will move on too as this is offtopic now, strictly speaking.
Now i got a got lead and will eventually figure it out.
@wakey
#1710 posted by killpixel on 2020/04/09 05:14:17
really cool project! photogrammetry with q3map2 and darkplaces is something I've wanted to experiment with for a while now.
quick question, why are you lightmapping this model? It's so dense why not just vertex light it? your results will be very good and cause fewer headaches.
you *can* lightmap something like this, but it can be a pain, as you've found. this will get worse in an actual scene with more complex lighting (like bounce).
don't underestimate the power of vertex lighting ;)
a test: https://imgur.com/a/e2lIirT
The Cavalry
#1711 posted by chedap on 2020/04/09 07:39:27
@kp, from the other thread, apparently the lightmapping is forced on anything that exceeds 1024 verts. That is, as long as "-meta" switch is on, which is the recommendation everywhere I looked.
1024 per surface would be alright actually, but contrary to that post, in practice bsp seemed to split the model into max 128 vert chunks here (while in the source default maxLMSurfaceVerts is 64?)
@wakey, if you do end up using vertex lighting, you might want to at least subdivide the top of the foundation a bit, so the lighting isn't stretched.
Seems I Underestimated
#1712 posted by wakey on 2020/04/09 09:26:50
vertex lighting after all.
Very beautiful screenshots @killpixel!
How did you get to be just vertexlit?
Leaving out -meta alltogether?
In general i would have no problem with leaving the -meta stage out, if i understood what the drawbacks of that actualy might be.
My guess is that -meta in reality might only be relevant for true idtech3 games, as those have a actual problem with surfaces exceeding 1024 verts, most notably Q3A itself.
With darkplaces on the contrary -meta seems to mess things up, not only for the models, but i also noticed some brushsurfaces not beeing properly lit by rt-lights when using -meta.
@chedap: thanks for the tipp, will do that.
Shedding Some Light
#1713 posted by killpixel on 2020/04/09 17:46:41
the test I posted is using -meta. from the wiki (which is probably pretty outdated):
At one time, there was a clear definition as to what, exactly, the -meta switch did. Now, it has become the "magic" switch that is required for most of Q3Map2's advanced features. Always -meta, and always -v.
I was under the impression it grouped neighboring triangles into larger lightmap islands because that worked better for things like phong shaded terrain.
Anyway, I forced vertex lighting on the model with a simple q3 shader script:
models/dev/maria
{
surfaceparm nolightmap
{
map models/dev/maria.tga
rgbGen vertex
}
}
surfaceparm nolightmap prevents lightmap generation, and rgbGen vertex tells the texture to grab the vertex data for shading.
I recommend learning more about q3 shaders. they're quite powerful, even with DP's limited implementation.
chedap is right, you should add some loops to the foundation and base if you're going the vertex lit route.
also, I'd avoid clipmodel ( spawnflag 2) for a model this detailed - use a clip brush instead.
Darn I'm Stupid
#1714 posted by wakey on 2020/04/09 20:10:19
could have thought of surfaceparm nolightmap<q/> myself, as i am familiar with q3 shaders ^^'
Anyhow, the model now looks as intented:
https://imgur.com/a/8Co4bUs
Thank you a lot, killpixel & chedap!
In return i could answer any questions regarding photogrammetry, if there are any.
Awesome
#1715 posted by killpixel on 2020/04/10 17:09:58
good luck with the project, looking forward to seeing more of it
Who Dat?
#1716 posted by R00k on 2020/04/25 00:09:49
who made this https://www.youtube.com/watch?v=SPWhp3KDxqM
shambler model. Is that Chillo's ??
the hands look diff. I just wanna give credit to my video.
Skiffy ?
#1717 posted by madfox on 2020/04/25 01:14:30
Speaking Of Shambler
|