Jump to content
The Dark Mod Forums

DR Ase exporter replaces textures randomly


Recommended Posts

Is it known that the ase exporter does not always get the textures right when exporting DR models into ase?

 

It seems to occur rather randomly.

Clipper

-The mapper's best friend.

Link to post
Share on other sites
  • Replies 80
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

OK, it seems I've fixed it now. But you may test it.   The problems are caused by the nan's.   I've changed the code so that if any nan's appear they'll be changed to zero. I did this only in the patc

I've made some changes to the script and it exports angua's example correctly. If there are any windows users here who experienced problems with wrong textures on exported model, it would be nice if t

Posted Images

I've only used it for a few models but never had an issue.

 

I did bug track the issue of naming them though.

 

instead of

 

//base/texture name

 

it exports

\\purgatory\purgatory\doom\base\textures\darkmod\carpet\rugs\ornate_black_gold01

 

It works now but I guess if we go stand-alone then there will probably be issues (not that it isn't easily fixed in text editor but...)

Dark is the sway that mows like a harvest

Link to post
Share on other sites

\\purgatory\purgatory\doom\

 

Is automatically ignored by the engine - It's not a huge problem to just batch remove it from all ASE's anyway.

 

Sotha - Does the geometry that you're exporting contain faces with caulk on it? afaik the script ignores that, and by doing that it might not be updating other references. I havent looked, but I have a feeling that it's possible.

Link to post
Share on other sites

Sotha - Does the geometry that you're exporting contain faces with caulk on it? afaik the script ignores that, and by doing that it might not be updating other references. I havent looked, but I have a feeling that it's possible.

 

Yes, there is caulk in there. The ase converter removes them from the resulting .ase though. And the some of the surfaces have a different texture in the .ase than it had in the original source brushwork.

Clipper

-The mapper's best friend.

Link to post
Share on other sites

This has been known for a long time, but nobody has a solution yet:

 

http://bugs.angua.at/view.php?id=3058

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites
  • 8 months later...

Generally, the ASE exporter seems to work very well. But often it seems to corrupt models on export. When you look into the .ase file, you see f.i. a lot of "nan" and "-nan" in the vertex normal lists.

 

Seems to happen most often with patches. Does anybody have a solution or is working on this?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

The objects have wrong shadows or sometimes black faces. Sometimes floating shadows, sometimes shadows on the wrong side. It seems particulary a problem with either cylinders, or cylinder caps.

 

Here is a model which exhibits that problem:

 

post-144-0-93960000-1355563455_thumb.jpg

 

And her is how it appears in game:

 

post-144-0-86067500-1355563746_thumb.jpg

 

Hard to tell if that are wrong shadows or simply black faces.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

I never saw this problem... Hey what if you use the patch inspector to enable fixed tessellation on that one and reduce the divisions a bit? Could this be something that happens when that is not enabled. I always use it in order to tune the tris-count versus appearance, so that the object still looks good but saves a few tris.

Clipper

-The mapper's best friend.

Link to post
Share on other sites

I never saw this problem...

 

Have you tried to export a cylinder-patch and a cylinder cap?

 

Hey what if you use the patch inspector to enable fixed tessellation on that one and reduce the divisions a bit? Could this be something that happens when that is not enabled. I always use it in order to tune the tris-count versus appearance, so that the object still looks good but saves a few tris.

 

The object already uses fixed tesselation. And it is not this object alone, here is another one that shows some floating shadows in the wrong places:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Have you tried to export a cylinder-patch and a cylinder cap?

 

Yes. I made different vaultings with end-caps as archs and bent cylinders to hide the seam between the end-caps. I've seen absolutely no problems it the produced models. Cylinders are not capped though, they hit the wall geometry so that the cylinders' end is hidden

Clipper

-The mapper's best friend.

Link to post
Share on other sites

It might be the cylinder cap, I'm still experimenting. It's very frustrating, because I've no spent several hours re-exporting and trying the same 2 models just to never get one that has no artifacts in game :(

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

I didn't have any problems with the ASE exporter either, although I didn't used it very much by now.

 

But I have had similar problems with func_statics: It sometimes happens that if I turn some Brush- and Patchwork into a func_static and use it multiple times beneath each other some of the tris on some of them where not drawn. If I instead turn them into two seperate func_statics and build up the same scenery as before, it works correctly.

 

So maybe this isn't a problem with the ASE exporter but something else went wrong when turning several patches and brushes into one entity

 

When you look into the .ase file, you see f.i. a lot of "nan" and "-nan" in the vertex normal lists.

Division by zero?! How are these normals computed?

 

If you rotate the entity by 90 degrees and export it then, does it look exactly the same?

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

I didn't have any problems with the ASE exporter either, although I didn't used it very much by now.

 

But I have had similar problems with func_statics: It sometimes happens that if I turn some Brush- and Patchwork into a func_static and use it multiple times beneath each other some of the tris on some of them where not drawn. If I instead turn them into two seperate func_statics and build up the same scenery as before, it works correctly.

 

So maybe this isn't a problem with the ASE exporter but something else went wrong when turning several patches and brushes into one entity

 

For me it appears regardless on wether I export multiple patches, or turn them them into one func_static first (the latter is nec. if you want to adjust the origin of the resulting model, as otherwise it is just the center of all patches/brushes, and for a lever, that does not work as it rotates around the origin.).

 

Looking closer it seems more or less a shadowing issue. Selfshadows cast by the cylinder etc. And it might tie into the normal issue below - if the normals are wrong, the shadows/shading might be wrong, too.

 

There is the additional problem that you can't set "smoothing" from DR - so a cylinder will not appear round but compromised of triangles. That can screw things up, too.

 

I know there is some way to render a "rectangluar brush" round (used to make round-appearing bars for grates) but I forgot how to achive that and google was no help. Is it a texture setting? a material shader property? Something on the func_static/model? I'm getting old...

 

Division by zero?! How are these normals computed?

 

If you rotate the entity by 90 degrees and export it then, does it look exactly the same?

 

Yeah, it does. But I have no idea how the python script computes the normals or what it does, really. Don't know much about python and very little about 3D math.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Of course, it is part of DarkRadiant. On Linux, you find it under /usr/lib/darkradiant/scripts/commands as ase_export.py.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

for count, data in enumerate(x[1]):
 normals += '''\t\t\t*MESH_FACENORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
  format(count, x[0][data[0]][5],x[0][data[0]][6], x[0][data[0]][7]) # greebo: use first vertex normal as face normal
 normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
  format(data[0], x[0][data[0]][5],x[0][data[0]][6], x[0][data[0]][7])
 normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
  format(data[1], x[0][data[1]][5],x[0][data[1]][6], x[0][data[1]][7])
 normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
format(data[2], x[0][data[2]][5],x[0][data[2]][6], x[0][data[2]][7])

 

Man, I hate python (no datatypes). This piece of code catched my attention (specially the part commented by greebo). I have only a rough idea what is meant by point normal, but I think it is something that depends on the face normals of all neighbouring faces. If so, than the point normal on a cylinder face won't look into the same direction as the face normal. And if these normals are used for shadowing, then this may cause some problems, especially if grid size on triangulation is reduced as the object seems relatively small.

 

(You may check that by recreating the same object the same way but with a finer grid - increased subdivide treshhold as MD told me)

Edited by Obsttorte

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

for count, data in enumerate(x[1]):
 normals += '''\t\t\t*MESH_FACENORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
  format(count, x[0][data[0]][5],x[0][data[0]][6], x[0][data[0]][7]) # greebo: use first vertex normal as face normal
 normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
  format(data[0], x[0][data[0]][5],x[0][data[0]][6], x[0][data[0]][7])
 normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
  format(data[1], x[0][data[1]][5],x[0][data[1]][6], x[0][data[1]][7])
 normals += '''\t\t\t\t*MESH_VERTEXNORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
format(data[2], x[0][data[2]][5],x[0][data[2]][6], x[0][data[2]][7])

 

Man, I hate python (no datatypes). This piece of code catched my attention (specially the part commented by greebo). I have only a rough idea what is meant by point normal, but I think it is something that depends on the face normals of all neighbouring faces. If so, than the point normal on a cylinder face won't look into the same direction as the face normal. And if these normals are used for shadowing, then this may cause some problems, especially if grid size on triangulation is reduced as the object seems relatively small.

 

(You may check that by recreating the same object the same way but with a finer grid - increased subdivide treshhold as MD told me)

 

You might be onto something :) So, could you fix this code? Just reducing the grid-size won't really work because the details get so small.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Instead of using the first vertex normal one could use the average value of all vertices belonging to the specific face

If all faces are triangles you have instead of

normals += '''\t\t\t*MESH_FACENORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''
 .format(count, x[0][data[0]][5], x[0][data[0]][6], x[0][data[0]][7])
 # greebo: use first vertex normal as face normal

something like

normal_x= (x[0][data[0]][5]+x[0][data[1]][5]+x[0][data[2]][5])/3
normal_y= (x[0][data[0]][6]+x[0][data[1]][6]+x[0][data[2]][6])/3
normal_z= (x[0][data[0]][7]+x[0][data[1]][7]+x[0][data[2]][7])/3
normals += '''\t\t\t*MESH_FACENORMAL {0}\t{1: 10.4f}\t{2: 10.4f}\t{3: 10.4f}\n'''.
format(count,normal_x,normal_y,normal_z)
# Obsttorte: use average vertex normals as face normals

You may test it

 

ase_export_changed.py.txt

 

Hope that's better.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

Increasing the division seems to help, one particular problem seem to be cylinders where the tris are not divided in the length of the cylinder.

 

Here is a DR screenshot of two cylinders, in green are marked artefacts in tris. The left has less artefacts, and the artefacts are in tris near one end. The other one has more artefacts due to the fact that the affected tris run the entire lenght of the cylinder.

 

post-144-0-02156200-1355574258.jpg

 

Increasing the tris around the circufence also reduces artefacts. But they are never entirely gone.

 

Here is one screenshot with r_showNormals:

 

post-144-0-07098400-1355574361_thumb.jpg

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

the first case definitely must have something to do with the way the face normals are computed (that doesn't happen in the script)

 

You have three conditions for the normal. Two are that the normal must be normal to the plane, so orthogonal to two linear independent vectors spanning the plane. The third condition is the direction the normal should point to.

 

And here comes the problem IMO. Setting up this problem leads to an linear equation system with three unknown (the entries of the normal vector).

This matrix has something that is called condition, what describes the way rounding errors influencing the solution. For the first two mentioned condition one would only write B*n=0, where B is a Matrix containing the first two lines of the full linear equation matrix and n is the normal vector. The rows in B are the two vectors spanning the plane.

 

The higher the difference in length of those vectors, the worse is the condition and the more will rounding errors be blown up!!!

 

The only two ways to bypass this are:

 

(i) make sure the triangles are close to an equilateral triangle (like in the first picture on the left cylinder)

 

(ii) preconditioning the system one has to solve in the code for computing the face normals (or changing the way it is computed)

 

EDIT: I'm not sure that's true but I think the code only uses single precision floating-point numbers, what increases the problem

 

EDIT2: A possible way for preconditioning is to take the second row and multiply it with l1 / l2, where l1 is the length of the vector in the first row and l2 the one in the second. This should decrease the problems a bit.

Edited by Obsttorte

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

Hope that's better.

 

Nope, sorry :(

 

post-144-0-36444000-1355575146_thumb.jpg

 

(The model is offset because the current exporter does not respect the origin of func_statics. The version that can, has not your fix and the "dont export caulk" feature. I'll have to merge these two scripts.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

well, it seems at least a bit better than in the first shot, or are the Patches used different :unsure:

 

are the face normals used for shadowing or only the point normals, maybe somethings wrong with the latter

Edited by Obsttorte

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to post
Share on other sites

All right, this is getting really really weird. I replaced one patch with a clipped brush, to see if that is better. That resulted in the entire model looking correct. If I export the all patch-version, it again is screwed up on all three parts !? :huh:

 

post-144-0-85287400-1355576805_thumb.jpg

 

You can see the brush (its not smooth) on the top side of the lever, and see the bottom is now correct, too! The two round cylinders in the background on the plate are part of the plate model, and incorrect.

 

Here is a map with what I used.

 

http://tunnels-of-da.../tmp/levers.map

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...