Converting GTKradiant "Prefabs" into ASE files?

[jal_]

Subdivisions specifies the number of sub divisions to make in your geometry. Larger values increase triangulation and as such, can decrease performance.

Is this wrong?

Yup, it is. Smaller values are the ones that produce more polys. I don't know exactly why, but my guess is that the correct name for the cvar/switch would have been subdivisionSize. Or maybe they inverted the behavior at some point.

[AEon]

For AEdm7 I added quite a few crates as deco in the map. To make them look more "realistic" I've given them a slight rotation, that already leads to texture alignment issues in GTKradiant 1.2.13, so I'm going ASE models.

How do I best turn on collision for the boxes?

Is it OK to cover the crate brush with playerclip, and then turn it into ASE, or is there another way that should be preferred.

Update: Well using a playerclip brush on the boxes pre-ASE compile is simply ignored by the game. So you either have to use spawnflags 6 for autoclipping on the model (if I read that correctly; wastes resources) or better manually playerclip everything. I'll be doing the latter.

[phantazm11]

Yeah, would be best to place the unrotated ASE in the map, playerclip it, then select both and and rotate.

Thanks for this...was looking for info on converting to ase...missed the caulk hull part. (I should have read Kat's tutorial)

[^misantropia^]

Code: Select all

call cd "I:\Games\Quake3\baseq3\maps"
call "I:\Games\!q3map2\q3map2.exe" -bsp -v -meta -patchmeta -subdivisions 32 "I:\Games\Quake3\baseq3\maps\%1.map"
call "I:\Games\!q3map2\q3map2.exe" -convert ase "I:\Games\Quake3\baseq3\maps\%1.bsp"
call copy /Y "I:\Games\Quake3\baseq3\maps\%1.ase" "I:\Games\Quake3\baseq3\models\mapobjects\solarae\"
call cd "I:\Games\Quake3\Radiant-bat"

For the UNIX geeks among you - that includes you, Mac users - please find below a script that automates building your maps and the prefabs they depend on. Drop it in your maps dir (or where ever, really), type `make` and you are good to go. The script:

Code: Select all

# add your maps here
BSP_FILES       =map01.bsp map02.bsp map03.bsp

DIR             =$(HOME)/.q3a/baseq3/maps
BSPC            =/usr/local/bin/bspc
Q3MAP2          =/usr/local/bin/q3map2

all:    $(BSP_FILES:%=$(DIR)/%)

# compile map to bsp
%.bsp:  %.map
        $(Q3MAP2) -bsp -meta $(DIR)/$<
        $(Q3MAP2) -vis $(DIR)/$@
        $(Q3MAP2) -light $(DIR)/$@
        $(BSPC)   -bsp2aas $(DIR)/$@

# compile prefab to ase
%.ase:  %.map
        $(Q3MAP2) -bsp -meta $(DIR)/$<
        $(Q3MAP2) -convert ase $(DIR)/$@

# maps + dependencies
map01.bsp:      map01.map prefab1.ase prefab2.ase
map02.bsp:      map02.map prefab2.ase

How does it work? Easy: set BSP_FILES to the maps you want compiled. If your maps don't use prefabs, that's it! Else, add an entry at the bottom like so:

Code: Select all

mycoolmap.bsp:   mycoolmap.map mycoolprefab.ase mycoolerprefab.ase

Done. Only thing left to do is tweak the parameters for the bsp/vis/light/bspc stages.

[^misantropia^]

And if you want it super easy, install inotify-tools, go to your maps directory and type:

Code: Select all

while true; do inotifywait -e modify *.map && make; done

Now every time you save a map or prefab, it and everything that depends on it will be recompiled.

[jal_]

A random bit of info I remembered when I was overviewing the early posts of this thread:

Picomodel has an internal hack to skip the use of material names in ASE models (not at other formats) when imported and when exported. It always forces the use of the texture name instead of the shader name. In practical use terms this means: If you want to use a shader (a light, the fan seen above) on an ASE model created with GTKRadiant make sure the shader name and the qer_editorImage name are the same.

[AEon]

For the UNIX geeks among you - that includes you, Mac users - please find below a script that automates building your maps and the prefabs they depend on. Drop it in your maps dir (or where ever, really), type `make` and you are good to go. The script:

You might like to mention that the script, by default has to be named makefile, for the make command to "simply" work. If you name the script differently, e.g. mk_mapname, you'd have to call: make mk_mapname (IIRC).

[^misantropia^]

Good point, I sometimes forget the obvious.

The file should be named Makefile (case sensitive) or alternatively, you can run it as:

Code: Select all

make -f mk_mapname

But you don't have to keep several copies around just to build each map individually because that is as easy as:

Code: Select all

make mycoolmap.bsp

[AEon]

I am wondering if make mycoolmap (no .bsp required) could not be made possible. "Yes, we are lazy ".

[^misantropia^]

Ain't she a beauty?

Code: Select all

# add your maps here
FILES   =map01 map02

BSPC    =/usr/local/bin/bspc
Q3MAP2  =/usr/local/bin/q3map2

all:    $(FILES)

$(FILES):
        @$(MAKE) $@.bsp

# compile map to bsp
%.bsp:  %.map
        $(Q3MAP2) -bsp -meta $<
        $(Q3MAP2) -vis $@
        $(Q3MAP2) -light $@
        $(BSPC)   -bsp2aas $@
        touch $@

# compile prefab to ase
%.ase:  %.map
        $(Q3MAP2) -bsp -meta $<
        $(Q3MAP2) -convert ase $@
        touch $@

# maps + dependencies
map01.bsp:      map01.map prefab1.ase prefab2.ase
map02.bsp:      map02.map prefab2.ase

[AEon]

Back to the topic of ASE models with shaders:

• Do light emitting shaders work on ASE models? I.e. do they actually emit light?

I seem to recall that they don't... hmmm...

[dONKEY]

Yes they can. All the lamp models in my NoGhost map are ASE models, and as you can see from the wip/screenshot thread, they clearly emit light. The 'Ripper's playground' map I did was entirely ASE models, and the lighting there was mainly from shader applied to the models.

[AEon]

Now that is convenient... I added "placeholder" lights in the map for now, and I'd hate to have to replace them every time I change/improve the lamp design, so an ASE model emitting light would be nifty.

As I understand it, light entities in ASE models will on the other hand *not* work, right?

[dONKEY]

Have never tried to ASE an entity...I'm assuming you can't, but don't know. You can place lights inside models...I always thought they would shine through shaders marked with surfaceparm alphashadow, but I've never got this to work.

[obsidian]

Light emitting shaders will work on ASE models, though you have to be careful doing so. IIRC, it will create a light source for every triangle (or quad) that the shader is applied to or something like that. ydnar explained it at one point but the general idea is that it's less than optimal.

Light entities in ASE models will work, it depends on the shader and properties of the misc_model entity.

[AEon]

So that I don't forget about ASE model lighting parameters:

• default (unset): vertex lit
  key: spawnflags / value: 2 = autoclip (vertex lit)
  key: spawnflags / value: 4 = lightmapped
  key: spawnflags / value: 6 = autoclip + lightmapped

I copied Sock's POM tree ASE into my map. It was set to spawnflags 2 and boy does that murder the AAS compile times. Autoclip cannot be recommended for complex models!

[jal_]

You can also put q3map_forceMeta on the light shader and it will make the light surface a metasurface and keep the rest of meshes as trisoup (I'm getting the habit of adding q3map_forceMeta to every light shader I do). But, in any way you do it, remember: the light shader name must match the texture name for exporting to ASE, or the model will be using the texture instead of the shader (you can also edit the ASE as text file).

[sock]

Just update the misc_model entry in your entities.def file (in your scripts directory) with this:

Code: Select all

//=============================================================================

/*QUAKED misc_model (1 .5 .25) (-16 -16 -16) (16 16 16) - CLIP LIGHTMAP
Generic placeholder for inserting .md3 models in game. Requires compilation of map geometry to be added to level.
-------- KEYS --------
angle: direction in which model will be oriented.
angles: X Z Y model direction for complex orientation
model : path/name of model to use (eg: models/mapobjects/teleporter/teleporter.md3).
modelscale_vec: X Y Z scale of model
_remap: Retexture ALL of the model surface with a different texture, must specify full path from baseq3 folder downwards. Works with the full Q3 directory tree structure.*/

The Autoclip function is useful with models that need to be precise on clipping (low to the ground and in frequent contact with player movement) Also if the model is not frequently used then it is fine to autoclip, just need to use common sense about each situation. You can always clip the model differently for bots or use the fixaas function if you want to fine tune the bot file better.

[AEon]

While we are at it one can add this line to the above entries.def entry for misc_model:

Code: Select all

spawnflags : 0 or unset vertex lights the model, 2 for vertex lighting with autoclip, 4 to lightmap the model, and 6 to lightmap the model with autoclip turned on.

or the complete text block (added a few spaces and one caps fixed):

Code: Select all

/*QUAKED misc_model (1 .5 .25) (-16 -16 -16) (16 16 16) - CLIP LIGHTMAP
Generic placeholder for inserting .md3 models in game. Requires compilation of map geometry to be added to level.
-------- KEYS --------
angle: direction in which model will be oriented.
angles : X Z Y model direction for complex orientation
model : path/name of model to use (eg: models/mapobjects/teleporter/teleporter.md3).
modelscale_vec : X Y Z scale of model
_remap : retexture ALL of the model surface with a different texture, must specify full path from baseq3 folder downwards. Works with the full Q3 directory tree structure.
spawnflags : 0 or unset yields vertex lighting, 2 for vertex lighting with autoclip, 4 to lightmap model, and 6 to lightmap with autoclip.*/

[Bliccer]

I copied Sock's POM tree ASE into my map. It was set to spawnflags 2 and boy does that murder the AAS compile times. Autoclip cannot be recommended for complex models!

Thanks for that, because I just wanted to ask if it is really so bad to use the autoclip function and if it let downward the frames (I read somewhere else).

Another thing: I have a tutorial about ase models which recommends t oedit the converted ase. So it says to delete every ".tga" or ".jpg" replace "\" with "/" and delete every "..\".
Now I don't read anything about editing in your posts...so I don't have to do that procedure?

[AEon]

Another thing: I have a tutorial about ase models which recommends to edit the converted ase. So it says to delete every ".tga" or ".jpg" replace "\" with "/" and delete every "..\".
Now I don't read anything about editing in your posts...so I don't have to do that procedure?

If you used q3map2 to create an ASE from a .map file you created yourself, you should not *need* to edit the ASE file, it should just work. I did do some editing on Sock's ASE (tree) model, because I had to fix the paths to point to the textures for my map (recommended to avoid future conflicts). And noted that under materials there are both paths with \ (DOS) and / (Unix) in them. Though I have no idea in how far editing those and the other things you point out really would improve anything.

[Bliccer]

I've just found this one:
map to ase tool

[obsidian]

That looks like just a front-end to Q3Map2.