ASE Export Script for Dark Radiant

[Fidcal]

Just downloaded this into the DR scripts folder but noticed there was not one there already. I understand this is already included in the latest DR update but where? Is it in the code? Is there no conflict? Well, guess I'll find out when I next export if there is no offset.

[Fidcal]

I confirm that it's OK. Just converted the harpsichord to a model! This is awesome! I'm only just beginning to realize the potential of this.

[Fidcal]

Don't know if this is an export script bug or what but yesterday I exported a model OK (back from Blender) and the material line in the .ase is...

 

*BITMAP "\\base\textures\misc\short_dry_grass_flagstones01_light_blend"

 

Today I made another similar model and exported it (from Blender) and in the .ase is...

 

*BITMAP "\\base\\\..\..\textures\misc\short_dry_grass_flagstones01_light_blend"

 

Obviously I can fix that but wondered what might be the cause?

 

Looking in the original export from DR I see...

 

*BITMAP "\\purgatory\purgatory\doom\base\textures\misc\short_dry_grass_flagstones01_light_blend"

 

This has got me wondering. I'd almost forgotten, after updating the DR export script I found it was getting the origin correct, ie, without the offset. That was OK. But today it is including the offset again. This makes me wonder again if there is some conflict between the one included with the latest DR and the script update? Has it reverted to the earlier one somehow? Or is the problem in the Blender export script?

[SneaksieDave]

Are the models okay in both editors, or messed up? Definitely looks like a problem...

[Fidcal]

I thought so - that is, they work OK. But I just noticed that neither of them has a visible origin. The origin values in Entity Inspector are sensible so they are not out of bounds but no visible origin icon in DR. In addition, the larger one is not selectable directly nor even by shift dragging around it. I can only select it via the Entity list.

 

Common factors are that both are flat patches. We never had totally flat models before did we? The one that is unselectable is a long path about 1200 long.

[Baddcog]

OK, been messing with this today.

 

Trying to export an ase directly to DR. (export, reload models, create...)

 

Working really good for patches. Just make sure it's worldspawn and at 0,0,0, no func_statics.

 

But brushes are a bit iffy. I have a well in my map, and figure why export as a prefab if I can do a model. So export and everything is fine except a few brushes have swapped textures on certian faces.

One brush was brick and caulk, now it's all brick. a copy of the same brush (or maybe the original) is fine.

 

Also one wood beam (brush) (out of about 10) is all caulk now instead of wood. The others are fine.

 

So I guess brushes in a big group have the possibility of their materials swapping.

-------

 

OK, I think it has to do with cloned brushes. I deleted the offending brick/caulk brush and recreated from scratch. Reimported perfect.

 

Deleted the cloned wood beam (remade from scratch), reimported and the caulk switch to another cloned beam, remade that from scratch and it's fine.

 

Doesn't suprise me, Max always had weird issues with cloned brushes in some programs.

 

So it's porobably not an issue to deal with, just something to keep in mind while making brush based models in DR. No Cloning!

[SneaksieDave]

That sounds a bit bad. If someone is going to prefab/model something, especially after building it, they probably weren't thinking in advance not to use their normal building technique (which likely includes cloning), and therefore will have problems. Can't imagine why it would happen anyway.

@rich: any ideas, can it be fixed?

[Baddcog]

Well, the good thing is it's easy enough to test (and probably fix).

 

I made my well not thinking about making a model from it. Then decided what the 'ell, might as well (get it?) make a model. I had to recreate 3 brushes to have it fixed (cloned patches are fine).

 

It is most likely mirroring that messes them up now that I think about it. There were several other cloned beams that didn't get messed up (they most likely were not mirrored).

[rich_is_bored]

It sounds like a bug in DarkRadiant to me. All the export script does is say "Hey, can you supply me with vertex, face, and material data for this brush or patch?" If that data is wrong, I have no way to validate it.

 

On a side note, I fixed the requirement that you build at 0,0,0 a while back. The version that's bundled with DR does not include this fix.

[Fidcal]

Ah - I forgot about that. I have a question: If the script sets the origin where does it put it? The mapper/modeller needs control because many models want the origin centre base, a door wants it on a leading hinge edge, a rotary wants it centre. Yes, we can load it into Blender and move the origin (or rather I think we move the model around the origin?) but preferable to not have to use Blender unless we really have to. For instance, it's more trouble to move the origin in Blender than just move the selected item in DR before exporting the model.

[rich_is_bored]

The updated script places the origin at the center of the selection. I presume it can be made optional so that you retain control when the need arises.

 

But I'm confused as to why people would be exporting models with no intention of further manipulation in a modeling package. Unless I missed something, there is no performance benefit to exporting a model over leaving map geometry as is. Quite the opposite in fact.

 

If the intention is merely to consolidate primitives into a group I fail to see why a prefab isn't the better choice. You retain the ability edit a prefab and the compiler will remove unseen faces. If you side with a model you lose both the above mentioned perks and the model renders in it's entirety whenever an adjacent vis-portal is open.

 

The only reason I can see to export as ASE is because you desire to take advantage of vertex colors, per-vertex UV coordinates, or smooth shading all of which require you load the model into a modeling package and make adjustments.

[Fidcal]

Yes that is true for most things because prefabs can be more easily resized, modified, retextured etc.

 

There are other reasons for making a model though. If you want to create a specific re-usable entity such as loot you cannot assign it in a def to brushes and patches (AFAIK.) Or if you want to make a moveable. Yes, you can create these in a map and assign the class for your own map and save that as a prefab but is that preferable?

 

For instance, I need to make some more royal loot for my FM and started with an orb. I'll probably also do a sceptre. I think these are better listed in the loot entities.

 

The slow match I made for Heart was just defined in the map with a simple brush but it would be better to produce a model entity imo, probably among lights.

[Serpentine]

I've been using the exporter to better optimize complex geometry that gets reused in many places, for example there are some pretty complex brush windows in the training mesh, while leaving them as func_statics is fine, moving them into models allows me to do all the culling by hand and drops the triangle count as well as avoiding quite a bit of compile time (I dmap in a window with my physical memory usage around 85% always ... so it makes a difference)

 

As for smooth shading, I don't think doom3 cares about vertex normals at all (but I cant say I've tested results with/without), all of the models that I export I generally just remove all vertex normal info and instead just put mesh smoothing on the relevant faces. I cant remember, but I think the doom3 parser actually just goes through the vertnormal list without using any values, might be worth checking out as irrelevant data like this could make people spend time tweaking models which would then not be 'right' in game. (tho exporting from blender should have an option to keep/remove as Im sure other games/things use it).

 

I dont know if you've fixed it, but your exporter also exports multiple matid's on a single onject. As far as I understand faces using different materials should be different meshes, I've noticed that a few apps that I work with discard any matid that doesn't match the meshes mat_ref.

[Baddcog]

The faces with different materials are probably divided into seperate meshes.

Which would leave a hard edge.

 

No reason to create 3 cubes if you want one cube with 3 textures.

 

Would be nice though if caulked faces could be culled from the model so they just weren't there anymore.

--------

 

As far as making models Fidcal is right, there are times when a model is best. Any kind of entity is a good example.

 

I made my well into a model and several windows and trims around it. Didn't really see a performance difference but didn't use show_primitives either. Should test the area but the window objects should drop the draw calls. Was locked at 30 fps both ways.

 

Sotha was messi

 

ng with 3d buildings in a skybox and I had him turn it into an ase. 800 draw calls turned into 250.

 

it's also nice having them in the models list instead of the prefabs (where you are divided between 2 menus to find stuff you want).

 

We can also make skins for models. And sure, a prefab is easier to skin in editor. But alot of people probably just want to place an object, choose a skin and go... Prefabs have issues with caulk, we have several already that probably have say 200 visible faces and 100 non-visible and non-caulked faces. Even if they are caulked if you want to change tex you have to be very careful not to undo the caulking... If it's a model the skins will leave caulk alone.

 

And most models are pretty small anyway, so if they are on screen they are rendering. If it's a func_static it would be the same. Maybe if it was split into seperate pieces it would cull better, but then you have alot of brushes/patches instead of one model.

[Tels]

But I'm confused as to why people would be exporting models with no intention of further manipulation in a modeling package. Unless I missed something, there is no performance benefit to exporting a model over leaving map geometry as is. Quite the opposite in fact.

 

Yes there is

 

* Map geometry is always included inline, meaning it is loaded/stored/manipulate multiple times. A model is cached, thus loaded, stored and processed only once. (technically, this also allows the GPU to load the model only once and draw it multiple times, this is called instancing. Unfortunately, D3 does not yet support it)

* models have other advantages (like not creating AAS info, unlike worldspawn), and a few other things that other people mentioned below.

* models can be used in LOD stages, func_statics not. (TDM v1.03 will support this)

* models can be more easily rotated.

* Basically, prefabs have many limits, and models can overcome a lot of them. as someone else already noted.

 

So, there are many reasons why you want to create models, and the ability to throw a few patches together and create a model (inside DR, which is easy to work with and already known) from them in invaluable to us.

[Serpentine]

Hmmm, it seems that it actually just applies smoothing to all ASE surfaces by default.It does not the smoothing flag on the faces at all, removing it completely results in all smooth, setting them to 0 all smooth again. Vertex normals are also disregarded and are recalculated on load. Maybe the hard crease is the only way :/

[Baddcog]

it is

[Serpentine]

Its not too much of an issue with vert count or anything, I was just hoping that normals were at least used so that smoothing anomalies could be corrected easily in non-manifold meshes. Maybe I'll end up doing this texure work after all... until I come up with a new bright idea!

[greebo]

On a side note, I fixed the requirement that you build at 0,0,0 a while back. The version that's bundled with DR does not include this fix.

Is the first post still linking to the most current version?

 

I'm asking because I could add support for func_statics (and for DR 1.5.0 it would be possible to export actual models too, but I won't write that).

[rich_is_bored]

Yes. That's the current version.

[greebo]

Ok, I'll be adjusting that one to include func_statics in the export.

[Tels]

Its not too much of an issue with vert count or anything, I was just hoping that normals were at least used so that smoothing anomalies could be corrected easily in non-manifold meshes. Maybe I'll end up doing this texure work after all... until I come up with a new bright idea!

 

Do you mean the ASE loader inside D3 that removes information when loading ASE files?

 

Technically, it would be possible to bypass that loader, but we'd need a ASE parser, and some trickery with my model generator (it would need to load the ASE itself, then you tell it to "replace" the ASE model with the newly loaded version). However, I am not sure it is worth all the effort (and we have no free developer anyway).

[Serpentine]

Technically, it would be possible to bypass that loader, but we'd need a ASE parser, and some trickery with my model generator (it would need to load the ASE itself, then you tell it to "replace" the ASE model with the newly loaded version). However, I am not sure it is worth all the effort (and we have no free developer anyway).

 

Oh no that's far too much effort - I'm just looking at ways to better use assets and such, so the more things stay the same in result and lower the time input, the better the method.

 

I also just enjoy the strange quirks of the engine

[Tels]

The new version to put the origin at 0,0,0 is nice, but it has a few bugs:

 

* a toggle to not put the origin at 0,0,0 is needed (or at least a simple X,Y,Z offset input field), Because I needed a model that was slightly offset (so it matches another models origin) and now I no longer can get this.

* if I select three patches and export them, somehow it also exports another caulk brush. I had to save the patches as prefab, import them into an empty map and then export as ASE.

 

Otherwise, it works splendid

[greebo]

Here's a new version of the ASE exporter script (version 0.5):

 

- Added support for func_statics

- Added checkbox to control the "Center objects at origin" option

ase_export.py.txt