ASE Export Script for Dark Radiant

[Tels]

Okay, I've looked over a test model in game in comparison to the patch mesh cone that it was exported from and the normals are considerably different. Oddly enough even though the cone model tapers off to a point, the normals continue to point outward as if it were still a cylinder.

 

I've also reviewed the script and as I suspected, nothing is being done to the normals. They are fetched and exported as is.

 

But I'm noticing something strange about the normals produced by a patch that makes me believe the engine treats them as a special case. As you know a patch cone isn't really a cone at all. It's just a cylinder where the vertices at one end are collapsed into a single point in space.

 

But those vertices are not merged. They remain separate and yet the vertex normals at that location point straight up. You shouldn't get normals like this unless the vertices are merged. Let me try and draft up an illustration real quick...

 

 

You can see this yourself if you use r_shownormals in game.

 

Ah, r_showNormals is very useful! As for the engine, well, you wouldn't want to believe want strange things they do to all the models after load... I am currently debugging an issue with automatically created backsides, finally found my error, but having documentation would have saved me a few hours today *sigh*

 

Back to the normals, what do we do about it? Should I just try a flat patch and wedge it into shape?

[Baddcog]

it's probably easy enough to edit the uv for the flat cap.

 

the difference between the cyl cap and cone is that the cap is probably just a flat patch with the corners pulled in to make it round. So in the tex tool you can probably pull the verts back out and the stretch will be almost gone.

 

with the cone you can never align the faces correectly because the tex tool only lets you edit the patch as one piece, due to cylinder mapping that will leave a bunch of tris across the top that can't be connected.

 

While you could probably merge those verts in Blender and that would help the smoothing, the tex still won't align without seams.

 

cylindrical mapping a cap is just a bad idea.

 

-----------

 

proper way to do cap. on the left we have a cap with a 'fit natural' texture. follow the blue arrow and you see in tex tool that it is just a square patch that is auto-rounded, but still mapped as a square. that causes stretch at sides of patch. to correct it apply the tex to a flat brush face, then copy paste shader to cap patch then it is mapped to it's actual; shape and you get no stretching.

 

but the normal on export probably stay flat, thus darker shading. this could be improved in Blender using the bent normals trick that was posted awhile back. However if you just create the model the same exact way in Blender you don't have to fix it. Thus the superiority of just making a model in a model program to begin with.

 

But you might also be able to simply renormalize the model in blender (instead of the trick). select all cap tris. add smoothing group.

 

 

 

a cone is mapped cylindrically. the issue here is that when you got to tex tool you have a big square, doesn't look like a cone. I drew in the polys in white, that's what a cylinders mesh would look like all the way up.

 

but the top of cone is pinched, the red shows the tris you see in game, see how none of the edges connect. that's why you can't align the tex. And it's always hard to get a cone to uv properly. In Max all the points would be together, but that means points on the sides stretch more than the ones in the middle, and the very edge(l/r) tris can never tile/align with each other, so it takes custom texture to make them 'align'.

that's what causes the tex tiling issue.

 

the blue tris are the shading issue. on a model, they just wouldn't be there, on the patch I'm not sure if they are there and just hidden/squished, or if they are actually removed, My guess is they are squished so they are squished into a line and that's what causes the shading issue.

welding the top verts in blender should fix smoothing, but not uv.

 

However there is no way with the tex tool to move those top tris on their own, so you can never fix that tiling issue.

 

However I did try and you can copy/paste from the top view from a cube and align the tex planar from the top like with the cap. it helps with the uv map up top, of course it stretches some as it goes down along the sides

 

so there's no perfect way to it. round things always get some stretch unless you can edit tris by themselves(model program) do do a custom tex so no seams.

----------

As far as patch/model export.

 

DR probably just smoothes one patch as one piece, where as models are based on smoothing groups, and if those top verts aren't welded, then they aren't one smoothing group(cone)

-------

in conclusion, to get the most of the ase export you need to learn a few simple steps in blender.

 

welding verts

adding smooth groups.

[Tels]

in conclusion, to get the most of the ase export you need to learn a few simple steps in blender.

 

welding verts

adding smooth groups.

 

Even your simple explanation was mostly above my head, how do you expect I learn blender on top of that, too? *sigh* I just go back to coding...

 

Anyway, thanx for the explanations, I will toy arund some more when I have free time. All I wanted was some simple mushrooms...

[Baddcog]

well, i don't know blender at all. but selecting verts and welding them should be pretty easy to do. I'm sure someone who knows blender could explain it and you learn in like 5 minutes.

 

Same with smoothing groups. you just select all polys on the top cap, hit apply smooth group, done.export.

 

I just don't know blenders interface.

[rich_is_bored]

It's entirely possible to construct suitable models from within DR without the need for further editing. The only reason it's an issue in this case is because patch cones aren't really cones.

 

What does that mean for someone who doesn't want to learn how to use a modeling application? Simple. Don't use cones. Use a flat patch for the cap and work the vertices into shape.

[Tels]

It's entirely possible to construct suitable models from within DR without the need for further editing. The only reason it's an issue in this case is because patch cones aren't really cones.

 

What does that mean for someone who doesn't want to learn how to use a modeling application? Simple. Don't use cones. Use a flat patch for the cap and work the vertices into shape.

 

(Also, using a cylinder cap isn't working either, because it is "pinched" at the sides, instead of the top. But I digres

 

As soon as I have a few minutes I'll try this and also write a wiki article. Mind if I re-use your pictures for it?

[Baddcog]

go ahead, but look at them closely, if you follow my copy/paste shader instructions there the cylinder cap patch pinching is eliminated (of course making it round will add a tiny bit of stretch, but not noticable.

 

it seems though that they have a normal issue also, where even after being bent the normals point straight up, thus giving the darker appearance. adding a smooth group to that in blender should be real easy to learn and should fix that issue.

------------

ah well , was going to make one and figure out how to smooth in blender, but blender is now only on my mint instal and don't have dr/doom running on it yet.

 

i did find though that its hard to make a nice round cap from a cylinder cap, you havve to asdd columns to begining and end, that makes it square again, so then you have to remake it round...

 

----------

we already have alot of mush, can't find one you like? want one of a different size?

[Tels]

we already have alot of mush, can't find one you like? want one of a different size?

 

Yeah, different sizes and shapes. I photographed a lot of them and figured they would be an ideal "beginners object". Obviously I was wrong

[rich_is_bored]

It would be awesome if the engine supported deformation modifiers like those used in modeling applications. The lattice modifier in Blender is a good example...

 

 

It's basically a cube that you place an object in and once linked you can move the vertices of the cube and it distorts the linked object. It would be very easy to scale and warp things with them. Unfortunately I'm not sure if that sort of thing is practical in a game engine but it's a cool thought.

[Tels]

@rich_is_bored:

 

I think there is a bug in the ASE exporter script. When you take a cube, and caulk one face, it seems to get exported with a different face caulked, or sometimes more than the face(s) you caulked, and sometimes less of them. Is there any chance the the code calulates the wrong material ref for some faces?

 

Here is what I exported and how the model looks like. It seems to always work when I use only one brush, but combine a few of them and it goes wrong in a semi-random fashion:

 

[rich_is_bored]

Make that object into a prefab and send it to me.

[Tels]

Make that object into a prefab and send it to me.

 

http://bloodgate.com/tmp/window_test.pfb

 

It contains a few more brushes, but just deleting everything except the three shown is enough, or use the entire object. So far I could not get any combination of more than two brushes to work correctly

[Robert]

I'm getting this error when trying to exort my telescope prefab to ASE.

 

Traceback (most recent call last):
File "/usr/lib/darkradiant/scripts/commands/ase_export.py", line 381, in <module>
execute()
File "/usr/lib/darkradiant/scripts/commands/ase_export.py", line 136, in execute
GlobalSelectionSystem.foreachSelected(walker)
File "/usr/lib/darkradiant/scripts/commands/ase_export.py", line 131, in visit
scenenode.traverse(nodewalker)
File "/usr/lib/darkradiant/scripts/commands/ase_export.py", line 117, in pre
processPatch(scenenode.getPatch())
File "/usr/lib/darkradiant/scripts/commands/ase_export.py", line 91, in processPatch
for x in mesh.vertices:
TypeError: iter() returned non-iterator of type 'iterator'

 

I think this is related to the fact, that I'm working with ArchLinux where python3 (/usr/bin/python3) is the default python interpreter. I do have python 2.7 installed as /usr/bin/python2. The file /usr/bin/python is merely a symlink to /usr/bin/python3. Changing this link to point to python2 has unfortunately not worked.

 

How does Darkradiant choose the python interpreter to run scripts with?

[Fidcal]

This is just to link to what I think is a script error here.

[Fidcal]

bump.

 

I'm kinda waiting on this. I downloaded the script again from the top of this thread hoping it was an earlier one than the one currently in DR but it has the same error. If it is a script error then effectively the script is totally disabled. I've sort of got to rely on it now so it's a problem.

 

In summary the horizontal surfaces of exported models are not lit by any local light. They are not black so presumably are lit by non-directional ambient light. It appears to be a normals error.

 

Sudden thought - I'll go back and test in TDM 1.05. If not I'll reload an earlier Dark Radiant.

[Fidcal]

I've tested in TDM 1.04 but the error is still there. I also re-installed an earlier Dark Radiant and still see the error. What I can't understand is that I've been using this script fairly often right up until the last few days it was working OK. I can't think what else could have changed recently. Maybe my previous models didn't have any horizontal surfaces and so the error never showed.

[rich_is_bored]

If you're counting on a fix in the immediate future, don't. I've grown tired of recurring issues and I don't want to commit any time to a fix unless I am confident it is going to be permanent. Keep in mind I'm a bit of an amateur at all this so progress is very slow.

[greebo]

If you tell me exactly what the issue is, please provide some test items / test map to reproduce that stuff - that can go to the tracker and I'll probably look into it some time.

[Fidcal]

OK thanks. On tracker at http://bugs.angua.at/view.php?id=2736

 

What I don't understand is that it was alright before and my earlier exports still seem OK. I've grown to rely on it for simple models, mostly moveables.

[Serpentine]

I'm getting this error when trying to exort my telescope prefab to ASE.

 

How does Darkradiant choose the python interpreter to run scripts with?

 

DR uses Boost::Python, as such it's more an issue of if you compiled it or not. I have a feeling that you compiled DR and bjam (urgh) picked your python3 to use. If this is the case and it's not a generic package you could make sure the bjam config is correctly configured to use python2 rather than the default. If it's a package you should talk to the maintainer - it's most likely someone here anyway

 

There's a less complete 3rd solution too!

Try using the 2to3 conversion tool included with python to translate the current script to python3 : > $ 2to3 /usr/local/share/darkradiant/scripts/commands/ase_export.py (or whatever the relevant path is).

 

And as always - let us know what was wrong/if you fixed etc - follow-ups save everyone time, even if there's no success

[greebo]

OK thanks. On tracker at http://bugs.angua.at/view.php?id=2736

 

What I don't understand is that it was alright before and my earlier exports still seem OK. I've grown to rely on it for simple models, mostly moveables.

I can confirm the issue, and the normals on the top of an exported cube brush are wrong (point to the left or right, not to the top like they should be - use r_showNormals 5 to visualise them).

 

I tried to import the ASE into Blender and upon re-export as ASE the normals are correct. I'll try to find the difference between the two ASEs.

[greebo]

Ah, that was an easy one. The transformation matrix in the ASE was off, the z-components were multiplied by zero:

 

*TM_ROW0 1.0000 0.0000 0.0000

*TM_ROW1 0.0000 1.0000 0.0000

*TM_ROW2 0.0000 0.0000 0.0000

*TM_ROW3 0.0000 0.0000 0.0000

 

By setting the value in the third row correctly (such that the matrix is identity) the model shows up fine in-game.

 

It's fixed now in SVN.

[Fidcal]

Thanks greebo. Just browsing DR SVN but I can't see it...

[greebo]

Take this: http://darkradiant.svn.sourceforge.net/viewvc/darkradiant/trunk/darkradiant/install/scripts/commands/ase_export.py?revision=6352

 

Put it into your install/scripts/commands folder, this should replace the existing one there. The next DR release will contain it anyway.

[Fidcal]

Thanks - confirmed working fine now!