:q3map?

(QESTUDENT) #1

From the q3map2 readme (2.3.29 (2002-11-03))

New: Add :q3map to the end of any shader name, and it will be interpreted as
the named shader minus :q3map. Example:
textures/shaderlab/concrete:q3map -> textures/shaderlab/concrete
One potential use is the -approx feature to collapse lightmapped surfaces
into vertexlit surfaces, saving lightmap space/memory

This has been making no sense for ages. :banghead:
Please help!

(chavo_one) #2

Here’s some info on the uses I’m familiar with for :q3map.
http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=5899&highlight=q3map#53471
http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=783&highlight=q3map#4380

If you want sense made for the -approx bit, I’ll defer to someone more knowledgeable.

(QESTUDENT) #3

Thank you, chavo_one, for those links! :cool:
Now it is clear that quake3.exe simply ignores :q3map but q3map2 does not.
Assuming quake3.exe has not been updated since 1.32pr, the feature quake3.exe ignores :q3map argument has been implemented from the begining?
I’ll try some experiments and report back the result later on.

(QESTUDENT) #4

I tried 2 experiments for about 30 minutes using the gamepack, quake3.
One is for operations “avoid the autosprited_flare_shader generated square shadow” and another for external lightmap.
For the former, I prepared 2 shader scripts,
a) models/bleh/autospritedflare
and
b) models/bleh/autospritedflare:q3map
The only difference between a) and b) is deformVertexes autosprite is written or not.
Then baked and ran my test map with b) on and off.
No difference. :blah:

As for external lightmap experiment, :banana: :clap: :banana:
This makes life far much easier than expected.
What has been thougt of nasty and annoying can now be eased. :cool:

Only one regret is this feature seems to have been implemented for ages. :banghead:

(cis) #5

u got external lightmaps to work in vq3? how did u make it work?

with -approx u can reduce the usage of lightmaps in the map considerably. Try -approx 50 and all lightmaped surfaces that are kind of uniformly lit will be turned into vertex lit surfaces by q3map2. If -approx 50 is too aggressive, try -approx 30 or lower.

(ydnar) #6

While busted in 2.5.13 (it’s fixed in 2.5.14-dev), the solid lightmap code pretty much does what -approx does but for all games, reducing solid lightmaps to a single pixel.

y

(QESTUDENT) #7

with -approx u can reduce the usage of lightmaps in the map considerably. Try -approx 50 and all lightmaped surfaces that are kind of uniformly lit will be turned into vertex lit surfaces by q3map2. If -approx 50 is too aggressive, try -approx 30 or lower.

Yes.
Though I’m still struggling with the relationship between :q3map and -apporx. :banghead:
Because -approx works without :q3map.

u got external lightmaps to work in vq3? how did u make it work?

below is an example with least argument

textures/qes/bleh
{
q3map_lightmapsize 512 512
qer_editorimage textures/qes/qer_bleh.tga
{
map textures/qes/heh.tga
}
{
tcGen lightmap // 1stly, tcGen lightmap
map $lightmap // 2ndly, mapping it
blendFunc filter // important thing here is their order
}
}

Additionally, by using :q3map, naming of bleh ,qer_bleh & heh can be unified, say, it makes less annoying and nasty to prepare an external lightmap for existing non-shader-manipulated textures like base_trim/pewter.

(megaman) #8

Why would the order be important?

(ratty redemption) #9

yeah, I have those 3 lines in different order to qestudent and the shaders are working.

(QESTUDENT) #10

Ydnar used to say q3map2 supports external lightmap for both native and non-native gamepack.(native=natively supports external lightmap)
This might be something to do with…just a guess though.