Jump to content
The Dark Mod Forums

DR Ase exporter replaces textures randomly


Recommended Posts

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

 

I used a higher subdivision, which restricts the artefacts to smaller triangles.

 

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

 

I have no idea, sorry :)

"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 comment
Share on other sites

I don't really see why you'd export the vertex normals. Unless you are exporting an existing model, the normals in the export will be the same one as the engine generates on load for shared vertices on load.

 

I spent a long time fighting them for the assimp exporter, only to find that it's almost always pointless to even supply them. In most cases you just add a lot of resource overhead.

Link to comment
Share on other sites

So, would the result differ on wether we export vertex normals or not? What is the relation of this to the issue at hand (the wrongly shadowed faces)? (Trying to understand 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 comment
Share on other sites

So, would the result differ on wether we export vertex normals or not? What is the relation of this to the issue at hand (the wrongly shadowed faces)? (Trying to understand this.)

 

The vertex normals can invert a whole face - leading the issues with shadow casting being incorrect, they can also do some strange magic which results in the face just looking shadowed when it should not be. A lot of the currently working models with custom VN supplied are only working correctly because the engine is actually ignoring them (only _some_ versions of the 3ds max export seem to work, other exporters seem to just be ignored, at worst result in rendering issues if they are used).

 

I'd really just not export them, see if it changes anything. Maybe leave it in as an option if there's benefit - sometimes the generated normals will smooth sharp edges, however it usually gets that correct.

Link to comment
Share on other sites

@Tels: yo, just checked the levers. I get drawing errors on both levers, but only on the patch parts. Will have a look.

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 comment
Share on other sites

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 patch part as the brushes seem to work.

 

# new function, checks for nan's
def checkNAN(x):
if x[5]!=x[5]:
 x[5]=0
if x[6]!=x[6]:
 x[6]=0
if x[7]!=x[7]:
 x[7]=0
return x

def processPatch(patchnode):
	verts = []
	faces = []
	shader = patchnode.getShader()
	# Tels: skip if caulk and no caulk should be exported
	if shader == 'textures/common/caulk' and int(GlobalRegistry.get('user/scripts/aseExport/exportcaulk')) == 0:
		return
	if not shader in shaderlist:
		shaderlist.append(shader)
	mesh = patchnode.getTesselatedPatchMesh()
	for x in mesh.vertices:
            # here goes the change !!!!!!!!!!!
	    verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]))  
            # here goes the change !!!!!!!!!!!
	tris = skinmatrix([x for x in range(len(verts))], mesh.width, mesh.height)
	for x in tris:
		x.append(shaderlist.index(shader))
		faces.append(x)
	geomlist.append([verts, faces])
	return

checkNAN is a new Function expecting a Vector that I've just put before the processPatch function

 

in the latter

verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])

has changed to

verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]))

Edited by Obsttorte
  • Like 1

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 comment
Share on other sites

@Obsttorte: If not exporting the normals (via checkbox defaulting to true) would work, then this might also slim down the resulting files.

 

Also, if you could maybe merge the code in that centers the result on the first found func_static? I can do this, too, but the less things distract from me Swift Mazes, the better :)

 

@Serpentine: Should we remove these from out existing ASE models with a filter? If so, I could whip something up.

"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 comment
Share on other sites

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 patch part as the brushes seem to work.

 

Cool. Do you have a full version, or do I need to merge your changes into my version? If so, can you please create a diff -u ?

"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 comment
Share on other sites

if you could maybe merge the code in that centers the result on the first found func_static?

 

I don't understand this sentence :unsure:

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 comment
Share on other sites

the only thing you have to do is to add the chackNAN function and to make the change in the processPatch function as described above

the code above shows the complete processPatch function so you could also just copy/paste it

 

If so, can you please create a diff -u ?

??? :blink: ???

 

donno what you want, sorry :rolleyes:

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 comment
Share on other sites

Cool. Do you have a full version, or do I need to merge your changes into my version? If so, can you please create a diff -u ?

 

Nevermind, I got it to work. As a side-effect, bumpmapping now works on these patches, which explains why they always looked blurry and flat to me - wow!

 

if you could maybe merge the code in that centers the result on the first found func_static?

 

There is a script named convert_to_ase_and_replace.py - it centers the resulting object by looking for the first func_static, and then uses its center as the center.

 

The current exporter can only either center around the center of the selection, or move this center to 0,0,0. Which means it always has the pivot point for rotations at the center of the selection, regardless on where you actually want it. Or in other words, before you export something where the origin/pivot point matters, you need to manually move it to 0,0,0 - which is highly cumbersome.

"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 comment
Share on other sites

If not exporting the normals (via checkbox defaulting to true) would work, then this might also slim down the resulting files.

during dmap

 

 

post-11230-0-56983400-1355583721_thumb.png

 

 

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 comment
Share on other sites

the only thing you have to do is to add the chackNAN function and to make the change in the processPatch function as described above

the code above shows the complete processPatch function so you could also just copy/paste it

 

 

??? :blink: ???

 

donno what you want, sorry :rolleyes:

 

Take both files, and run (on linux, on console):

 

diff -u file1 file2

 

This produces something like this:

 

root@te:/usr/lib/darkradiant/scripts/commands# diff -u ase_export.py ase_export_2.py
--- ase_export.py	   2011-11-26 22:59:06.000000000 +0100
+++ ase_export_2.py	 2012-12-15 16:02:26.000000000 +0100
@@ -19,14 +19,14 @@
#TODO:

# Set the command name so that DarkRadiant recognises this file
-__commandName__ = 'aseExport'
-__commandDisplayName__ = 'Export ASE...'
+__commandName__ = 'aseExport2'
+__commandDisplayName__ = 'Export ASE (fixed)...'

# The actual algorithm called by DarkRadiant is contained in the execute() function
def execute():
 script = "Dark Radiant ASCII Scene Export (*.ase)"
-    author = "Richard Bartlett, some additions by greebo and tels"
-    version = "0.7"
+    author = "Richard Bartlett, some additions by greebo, tels and Obsttorte"
+    version = "0.8"

 # Check if we have a valid selection

@@ -85,6 +85,15 @@
	 geomlist.append([verts, faces])
	 return

+    def checkNAN(x):
+	   if x[5]!=x[5]:
+		   x[5]=0
+	   if x[6]!=x[6]:
+		   x[6]=0
+	   if x[7]!=x[7]:
+		   x[7]=0
+	   return x
+
 def processPatch(patchnode):
	 verts = []
	 faces = []
@@ -99,7 +108,7 @@
		 shaderlist.append(shader)
	 mesh = patchnode.getTesselatedPatchMesh()
	 for x in mesh.vertices:
-		    verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])
+		   verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]))
	 tris = skinmatrix([x for x in range(len(verts))], mesh.width, mesh.height)
	 for x in tris:
		 x.append(shaderlist.index(shader))
@@ -309,7 +318,10 @@

			 normals = str()
			 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
+				    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
				 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])

 

This is called a "unified diff" and it shows exactly which lines get changed, added or deleted, and sourrounding context (so you see where it was changed).

 

As a bonus, one can take such a file and use the "patch" program to apply the difference to the local version. This even takes into account that maybe the local version got already modified, patch will merge the differences.

 

Makes life a lot easier than copy&pasting line from a forum into a file and hoping one got the correct 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 comment
Share on other sites

There is a script named convert_to_ase_and_replace.py - it centers the resulting object by looking for the first func_static, and then uses its center as the center.

 

The current exporter can only either center around the center of the selection, or move this center to 0,0,0. Which means it always has the pivot point for rotations at the center of the selection, regardless on where you actually want it. Or in other words, before you export something where the origin/pivot point matters, you need to manually move it to 0,0,0 - which is highly cumbersome.

I see it, the code processing the patches is the same, so are the changes. :smile:

For the latter, do you want to have something like an offset functionality or is this just for explanation?

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 comment
Share on other sites

 

 

--- ase_export.py	2012-12-15 16:02:31.000000000 +0100
+++ ase_export_old.py	2012-06-12 00:04:47.000000000 +0200
@@ -85,15 +85,6 @@
	 geomlist.append([verts, faces])
	 return

-	def checkNAN(x):
-	if x[5]!=x[5]:
-   	 x[5]=0
-	if x[6]!=x[6]:
-   	 x[6]=0
-	if x[7]!=x[7]:
-   	 x[7]=0
-	return x
-
 def processPatch(patchnode):
	 verts = []
	 faces = []
@@ -108,7 +99,7 @@
		 shaderlist.append(shader)
	 mesh = patchnode.getTesselatedPatchMesh()
	 for x in mesh.vertices:
-			verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]))
+			verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])
	 tris = skinmatrix([x for x in range(len(verts))], mesh.width, mesh.height)
	 for x in tris:
		 x.append(shaderlist.index(shader))

 

 

 

 

--- convert_to_ase_and_replace.py    2012-12-15 16:13:09.771532991 +0100
+++ convert_to_ase_and_replace_old.py    2012-12-15 16:14:09.683830077 +0100
@@ -90,15 +90,6 @@
	 geomlist.append([verts, faces])
	 return

-    def checkNAN(x):
-    if x[5]!=x[5]:
-   	 x[5]=0
-    if x[6]!=x[6]:
-   	 x[6]=0
-    if x[7]!=x[7]:
-   	 x[7]=0
-    return x
-
 def processPatch(patchnode):
	 verts = []
	 faces = []
@@ -108,7 +99,7 @@
		 shaderlist.append(shader)
	 mesh = patchnode.getTesselatedPatchMesh()
	 for x in mesh.vertices:
-		    verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]))
+		    verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])
	 tris = skinmatrix([x for x in range(len(verts))], mesh.width, mesh.height)
	 for x in tris:
		 x.append(shaderlist.index(shader))

 

 

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 comment
Share on other sites

I see it, the code processing the patches is the same, so are the changes. :smile:

For the latter, do you want to have something like an offset functionality or is this just for explanation?

 

I'd thought that the current ase_export.py would get instead of the single "center at 0,0,0" checkbox a setting (selection between 3 items) that says:

 

* don't center (export as is)

* move the center of the selection to 0,0,0

* move the origin of the first func_static to 0,0,0 (the way the convert_to_ase_and_replace.py works)

 

In the last case, it would just find the first func_static and use it's center. The "replace the model in DR" is useless, because most of the time it just repaces it with a "unknown shader box" because the exporter model is exported to a directory that DR can't read directly). So I think the "center at func_static" is needed, but the replace can be done by the mapper manually by "reload models".

 

Does that make sense?

 

 

Btw, with your fixes, btw does the new way of computing the normals change anything if they are thrown away by the engine,anyway? Not quite understanding 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 comment
Share on other sites

 

 

--- ase_export.py	2012-12-15 16:02:31.000000000 +0100
+++ ase_export_old.py	2012-06-12 00:04:47.000000000 +0200
@@ -85,15 +85,6 @@
	 geomlist.append([verts, faces])
	 return

-	def checkNAN(x):
-	if x[5]!=x[5]:
-   	 x[5]=0
-	if x[6]!=x[6]:
-   	 x[6]=0
-	if x[7]!=x[7]:
-   	 x[7]=0
-	return x
-
 def processPatch(patchnode):
	 verts = []
	 faces = []
@@ -108,7 +99,7 @@
		 shaderlist.append(shader)
	 mesh = patchnode.getTesselatedPatchMesh()
	 for x in mesh.vertices:
-			verts.append(checkNAN([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()]))
+			verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])
	 tris = skinmatrix([x for x in range(len(verts))], mesh.width, mesh.height)
	 for x in tris:
		 x.append(shaderlist.index(shader))

 

 

 

Yes, that's it :) I added your nickname to the credits and increased the version, too.

 

Here is a tracker entry where I posted the result: 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 comment
Share on other sites

nice, thanks

 

Btw, with your fixes, btw does the new way of computing the normals change anything if they are thrown away by the engine,anyway? Not quite understanding this.

To avoid misunderstanding, the problem with the shadows where caused by the vertex normals while the dmap error shown above was caused by deleting the line that exports the face normals. So if you relly want to not export it, you'll have to tell the engine that it should ignore it if they're not there.

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 comment
Share on other sites

Here is how it looks, beautyful:

 

post-144-0-84675000-1355584970_thumb.jpg

 

(Ignore the cylinders holding the handle, these are WIP and have the wrong texture scale)

"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 comment
Share on other sites

To avoid misunderstanding, the problem with the shadows where caused by the vertex normals while the dmap error shown above was caused by deleting the line that exports the face normals. So if you relly want to not export it, you'll have to tell the engine that it should ignore it if they're not there.

 

Ah, ok, thanx. Fixing the engine is for somebody else on another day :)

"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 comment
Share on other sites

:laugh: :laugh: :laugh: yup

 

for the center problem, the export script does also work with just patches/brushes selected and therefore must not get a center, and 'use center of first func_static' may be a bit confusing to most mappers (how should they know which one is the first)

 

if restricting the script (or a coy of it) to only one func_static, using its origin may be something to add, as this can be changed rather easy in DR and is quite useful for movers like your lever

 

when working with several funcs or brushes/patches an offset may be the best choice as a further option:

 

- surround the 'object' with the smallest cube containing it

- take the point with the lowest x,y,z-values

- add the user-specified offset to this value =new origin

 

or maybe an offset from the center, donno

 

IMO a separate script only taking one func_static into account is the best solution here

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 comment
Share on other sites

:laugh: :laugh: :laugh: yup

 

for the center problem, the export script does also work with just patches/brushes selected and therefore must not get a center, and 'use center of first func_static' may be a bit confusing to most mappers (how should they know which one is the first)

 

Well, the first one you select (some of operations in 3D depend on the selection order like boolean logic :)

 

if restricting the script (or a coy of it) to only one func_static, using its origin may be something to add, as this can be changed rather easy in DR and is quite useful for movers like your lever

 

when working with several funcs or brushes/patches an offset may be the best choice as a further option:

 

- surround the 'object' with the smallest cube containing it

- take the point with the lowest x,y,z-values

- add the user-specified offset to this value =new origin

 

or maybe an offset from the center, donno

 

IMO a separate script only taking one func_static into account is the best solution here

 

The problem is that you then have to maintain two scripts.. Why not add the small code that takes the first func_static and add it to the first, if there is no func_static fallback to the default?

 

Also, always thinking about which script to use to export which object gets tedious. I have already half a dozend models, and if I change the texture or some detail, I need to re-export alot of models including their LOD variants. So every step less helps :)

"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 comment
Share on other sites

I understand

 

btw.: I just made a script that should export a single func_static and keeping its origin, but it doesn't occur in the scripts menu, although I've reloaded the scripts and even restarted DR. I wanted to test it before I merge anything strange into the existing scripts.

 

Can you tell me what I have to do to gain access.

 

If it works I would than try to add a checkbox keep origin if only one entity or so

 

EDIT: is this texture switch problem still occouring?

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 comment
Share on other sites

fixed the problem, wrong indentation (f%&?ing python)

 

EDIT: just tried it out, keeping the origin works nice :smile: will merge it into the other

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 comment
Share on other sites

Cool, looking forward to it.

 

And yes, I think the texture switch problem is still occuring, but I'm not sure (you can test this with a single brush and multiple textures, one of the sides being caulk, I think).

"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 comment
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.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 1 reply
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...