Converting GTKradiant "Prefabs" into ASE files?

[AEon]

This is really old issue, but since I have never done this, some pointers to the right tutorial would be very much appreciated, and any tips on what *not* to do as well.

I created a new JP for SolarAE that uses several shaders, in one case I need to rotate it - x-axis by 45° - and that lead to off-1u-grid brushes. Since I use that pad four times, fixing it properly once, might be a good thing.

Hopefully, as I understand it, I can build the to be ASE in GTKradiant, and texture it etc. to then convert it?

[$NulL]

There's a few tutorials around, they're all pretty lengthy considering its such a simple thing. *shrugs*

1 http://www.katsbits.com/htm/tutorials/c ... models.htm
2 http://forums.urbanterror.net/index.php ... 746.0.html
3 http://en.wikibooks.org/wiki/Q3Map2#Cre ... _brushwork


Or in fewer words, allow me:

1: In a new map file create your brush geometry at/near the world's origin point (0,0,0). The worlds origin will become the models origin when placed in back radiant.

2: Place a hollowed out caulk hull around the brushes, add a single entity (a player start will do) so the compiler is happy.

3: Compile this map to a .bsp file using -meta (and -patchmeta if needed); you dont have to vis or light it.

4: Run the new .bsp through q3map2 while specifying the -convert switch and out pops an ase model of your brushes.

[Kat]

There's a few tutorials around, they're all pretty lengthy considering its such a simple thing. *shrugs*....

Yes, and you'd be surprised how often and how many times people fcuk this up .. given how much of a "simple thing" it is and all... *doubleshrug*

[AEon]

$NulL,
thanks for the heads up... I was guessing a few things like the origin placement, and hull obviously makes sense. Cool, will try that tomorrow... I might like this so much that I'll start my own ASE lib ... then again each map still has it's own stuff... sooo...

Hipshot warned me about the rotation of brushes and issues with them, but you only really understand such issues if you actually try them yourself, and have real problems.

[Hipshot]

A good bat file, makes it real simple.
http://zfight.com/wiki/index.php/Q3map2_ase_batch_file

And for everyones information, there's no need to caulk hull the map before if it's just brushes with normal shaders on them. Just make the shape you want and you're ready to go.
And even if you need to caulk hull, there's no need for any player start.

[Delirium]

add a single entity (a player start will do) so the compiler is happy

Correct me if I'm wrong but I havn't needed to do this and it has worked out fine without a spawn, so it should be ok to not add one

Edit: just saw that hipshot just said this >.>

[AEon]

I have all my compile scripts in the I:\Games\Quake3\Radiant-bat folder, and via key-combo I can quickly run a "shell" from that folder from my file browser (Directory Opus):

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"

The first cd to the maps folder was required to "motivate" q3map2 to actually place the .bsp there, IIRC (been a long time since I changed my scripts). The .ase file is then copied (force overwrite) into the "proper" mapobjects folder, I'll have to change that folder on a per map basis, but that is relatively simple.

I noted that one of the FAQs uses "-convert ase", Hipshot and $NulL don't use the "ase" part, I also saw a "-game [game abbreviation]" parameter. What is the [game abbreviation] for Q3A, "quake3"?

[AEon]

Some notes:

• As pointed out you simply place the brushes (patches, need testing) in an empty map at the xyz origin.
• The POO, point of orientation should thereby *not* be *in* a structural brush!
• No need for a caulk hull, or any hull at all, or a player spawn point for that matter.
• Do *not* make or keep those brushes detail, they *have* to be structural.
• I used caulk on all faces that are not to be shown, and nodraw on the invisible sides of shaders with transparency (e.g. floor grate/fence).

WYSIWYG and model angles does not seem to work? I wanted the model to be rotated 45° on the x-axis. It seems you have to give the model a angles (X Y Z, I presume) parameter: 45 0 0 should have done it, but for some reason, it has to be -45 90 0 (at least the alignment angle then sorta fits in-game).

In relation to XYZ-axes in GTKradiant, how do I need to imagine the "angles" axes are actually orientated?

Shaders with transparency used in an ASE, e.g. grates, do not show in GTKradiant, this is normal? In-game things seem to work fine.

[dONKEY]

Are you using an older version of GTK? I think the WYSIWYG rotation only works in 1.5

[AEon]

Are you using an older version of GTK? I think the WYSIWYG rotation only works in 1.5

Got me there, I am still using GTKradiant 1.2.13... oops ... I used to have 1.4 and 1.5 installed (1.5 was for Q4 mapping IIRC)... hmmm...

[AEon]

It seems that one has to be careful with the shaders one uses on ASE models. I have created a jump pad out of brushes, and that works just find in the editor and in-game, transparency etc. Now when I convert the JP to ASE, I get the lighting issue on the right:

• 

The shaders work just fine in the map elsewhere but not in the ASE model:

• Code: Select all

  textures/solarae/fan
  {
  	qer_editorimage textures/sfx/fan.tga
          surfaceparm trans
  	surfaceparm nonsolid
          surfaceparm nomarks
  	//cull none
          nopicmip
  	{
  		clampmap textures/sfx/fan.tga
  		tcMod rotate -100
  		blendFunc GL_ONE GL_ZERO
  		alphaFunc GE128
  		depthWrite
  		rgbGen identity
  	}
  	{
  		map $lightmap
  		rgbGen identity
  		blendFunc GL_DST_COLOR GL_ZERO
  		depthFunc equal
  	}
  }
  
  textures/solarae/fence
  {
  	surfaceparm trans
  	surfaceparm nonsolid
  	surfaceparm alphashadow
  	qer_trans 1
  	cull none
          nopicmip
  	{
  		map textures/solarae/fence.tga
  		//tcMod scale 3 3
  		blendFunc GL_ONE GL_ZERO
  		alphaFunc GE128
  		depthWrite
  		rgbGen identity
  	}
  	{
  		map $lightmap
  		rgbGen identity
  		blendFunc GL_DST_COLOR GL_ZERO
  		depthFunc equal
  	}
  }

Both the rotating fan and the fence (grate in this case) above it, seem to be far too bright. The normal textures I use for the JP border a lit normally. Any help appreciated.

[obsidian]

As far as rotations go, older versions of GtkRadiant had a bug where the rotations in the editor were displayed incorrectly, one of the axes was reversed with another (can't recall which one). It's fixed with 1.5 and I think 1.4 as well.

Models by default are not lightmapped. You have to manually set them with "spawnflags 4" in the entity inspector.

For smaller decorative models, you're probably better off with vertex lighting, but you'll need a separate shader.

Code: Select all

// Vertex lit shader
textures/solarae/fan_vertex
{
	noPicMip
	surfaceparm nomarks
	// Models are by default nonsolid unless you set clipmodel
	// (spawnflags 2). Only use clipmodel on larger models with
	// polygons larger than 8 units. Use manual clip brushes otherwise.
	surfaceparm nonsolid
	surfaceparm trans
	qer_editorImage textures/sfx/fan.tga
	//qer_trans 0.999		//GtkR 1.4 and older
	qer_alphaFunc gequal 0.5	//GtkR 1.5 (use one, not both)
	{
		clampmap textures/sfx/fan.tga
		alphaFunc GE128
		depthWrite
		tcMod rotate -100
		rgbGen vertex
	}
}

Also, no need for GL_ONE GL_ZERO, that basically specifies the default behaviour (no blendFunc)

[AEon]

Thanks for the help, I doubt I would have come up with a fix. I changed the fence/grate shader accordingly:

• Code: Select all

  textures/solarae/aejp_solar_grate
  {
      noPicMip
  //  surfaceparm nomarks         // Grate should show marks
      surfaceparm nonsolid
      surfaceparm trans
      qer_editorImage textures/solarae/fence.tga  // Required to see it in GTKradiant
      qer_trans 0.999             // GtkR 1.4 and older
  //  surfaceparm alphashadow     // Possible?
      cull none                   // Required by grate?
      {
          map textures/solarae/fence.tga
          alphaFunc GE128
          depthWrite
          rgbGen vertex
      }
  }

I am not sure about the surfaceparm alphashadow and cull none commands though.

Applied your changed shader and the one above and using them specifically for the ASE.

[obsidian]

Models are by default, vertex lit. For small decorative models like those used in Q3A, it's usually the best solution.

But if you are using a shader, you have to specify that the surface is to be vertex lit, not lightmapped, with rbgGen vertex and leaving out the lightmap stage.

Sometimes, you have larger, architectural or terrain or whatever models which will look better lightmapped. For these, you have to tell the model that you want it lightmapped by setting the spawnflags 4 bit value.

In general, models with small surface geometry (small polygons) look better vertex lit, objects with larger polygons will look better lightmapped. Vertex lit objects have an additional performance benefit so there are perhaps specific times when you may want to force vertex lighting.

[AEon]

The vertex lighting (i.e. the specifically changed shaders for the fan and grate), look better than the initial "over-brite" issue, but the fan/grate textures are simply too dark. When I use the default shaders for the fan/grate again and apply spawnflags 4 to the models, I have to say the lightmapped model looks a lot better.

• 

Using lightmap for now.

[AEon]

On having to build a caulk hull around the to be "ASE models", plus having to add a info_player_deathmatch, I seem to have been wrong. For very simple models, in my case one brush with a grate shader, I had to build the hull. The ASE conversion would otherwise cause an compile error and fail.

Live and learn .

[Kat]

I could have sworn I wrote something about that in my *cough*lengthy*cough* tutorial.. lol

[AEon]

Kat's: How to.. Converting/exporting maps as models

I actually read it up to the point of using that Q3map2Tools frontend, I seem to be of the HardQore crowd still using batch files

[jal_]

Simple silly addition: I have all the export to ASE options added to the netradiant menus (In fact, I did it for netradiant's warsow.game, so everyone using it for mapping for Warsow has it). It's, of course, the same thing as using batch files, but makes things so much simpler that it kinda changes the way you look at them.

If anyone wants it and doesn't know how to do this stuff, the build menu is downloadable here: http://opensvn.csie.org/warsowgamepack/ ... rsow.game/



Of course you still have to create the caulk box and add the spawnpoint, but not having to go to the batch file saves a lot of time already.

EDIT: Notice: The "test" and "final" builds are for the QFusion engine. They should not be used for quake 3 engine maps.

[AEon]

I noted even in the old GTKradiant build (1.2.13) there are "prefab macros" (it's probably hard coded though), like "create a death pit"... a "create caulk hull for ASE" would be a fun thing to have. Simply select the ASE, the editor then checks the maximum dimensions, to create a default box with player spawn. Just musing...

[Delirium]

subdivisions 128 O______O

you actually use that? thats a bit harsh on the engine right? I usually never go above 4 or 8

[Hipshot]

Depends on the model and the situation - that's my opinion about subdivs on models...

[jal_]

subdivisions 128 O______O

you actually use that? thats a bit harsh on the engine right? I usually never go above 4 or 8

I've never used the 128 one yet, but I did use the 64 one a couple of times, and the 32 one quite frequently. I don't get why you say it would be harsh on the engine, tho. I'd say the harshest on the engine one is subdivisions 2 (which I've used too :P). It all depends on the size of the model and the need of detail in the curve anyway.

[Delirium]

Wait... I think I've misunderstood subdivisions
the way I interpreted it was the higher the number the more divisions is given to the patchmesh (which I understood from this).... Is this wrong?

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

[Hipshot]

Wait... I think I've misunderstood subdivisions
the way I interpreted it was the higher the number the more divisions is given to the patchmesh (which I understood from this).... Is this wrong?

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

It does.