Does anyone know the best way to reach them?
Try it with a private message.
Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.
Die Registrierung und Nutzung ist selbstverständlich kostenlos.
Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.
Das Team der Transport-Fever Community
Does anyone know the best way to reach them?
Try it with a private message.
I sent a private message Merk and I see he's been online since then, but he doesn't seem to have read or replied to my message. Is anyone in this thread in regular contact with him?
Thank you eis_os for permission and thanks Yoshi for poking Merk I now have permission from all previous authors to release Version 0.6.0 of the plugin under a CC BY-NC-SA 2.0 License (https://creativecommons.org/licenses/by-nc-sa/2.0/)!
I guess releasing this to the community makes it a beta version. I should point out that my own internal testing really only tested one workflow (import a stock TpF2 loco -> export it -> view in TpF2 Model Viewer or game, all with Blender 2.77a), so other workflows may well be very buggy. The intent was that the following workflows would remain functional:
...but I didn't explicitly test that these still work, so it is entirely possible that they don't. If you find that they don't, please reply with a bug report (suggested format below) and I will see whether I can fix the issue. Cross-game workflows (TF->Blender->TpF2) wasn't a design goal.
Some notes on configuration:
I also changed some settings (like how spacing is inserted in exported files) so that the output files look more similar to the originals in TpF2.
Important Notes:
Bug Reports:
Please follow the following format:
Steps to reproduce:
Expected Behavior: [describe]
Actual Behavior: [describe]
Vague bug reports will be ignored. Remember that I know more about programming than about Blender
Known Issues:
Feature Requests:
I am unlikely to entertain these unless they seem like core features which I've overlooked, but anyone is welcome to advance the project themselves under CC-BY-NC-SA 2.0.
Hello
Thx for your work i just testet it and found a bug and a suggestion:
The format of the zip file is wrong. Blender expects for an automatic installation from a zip, what is a folder in the zip and then the plugin in this folder.
As you thought about the textures, it doesn't make sense for a modder, you need the UVW flipped for export and if I have like 120 mesh on a steam locomotive then I don't feel like doing that by hand. I don't care that the textures are upside down, I don't need them.
So please make a option to flip the UVW again during the export or include an option for the import so that the UVW does not flip during import.
As it is now, I would not (want to) use the plugin.
Didn't yet time to test you changes.
As you mentioned flip image, my local fork I touched last year uses this:
def flip_image_fast(image):
width = image.size[0]
height = image.size[1]
new_pixels = list()
old_pixels = list(image.pixels[:])
for i in range(height-1, -1, -1):
new_pixels += old_pixels[4*i*width:4*(i+1)*width]
image.pixels = new_pixels
Not sure if it really is faster on all systems, technical with older blender versions the list function was faster in my tests.
About dds textures, my fork converts the dds textures to tga while importing or using the tga texture if it's found.
But the plugin constantly crashed on linux in the plugin system so I stopped development, not sure if this helps:
def convertDDSToTGA(ddsfilename, filename):
if isfile(filename):
print("Using tga " + filename + " as replacement for " + ddsfilename)
else:
print("Trying to flip image data" + ddsfilename + " writing to " + filename)
newdata = load_image(ddsfilename)
newdata.filepath_raw = filename
newdata.file_format = 'TARGA'
flip_image_fast(newdata)
newdata.save()
bpy.data.images.remove(newdata)
return filename
Alles anzeigen
class TF_base_functions():
@classmethod
def get_data(cls, filename, type, errors = []):
...
if (type == "IMAGE"):
if (filename.endswith(".dds")):
ddsfilename = filename
filename = os.path.splitext(ddsfilename)[0]+".tga"
if (isfile(filename)):
pass
elif (isfile(ddsfilename)):
from .image_util import convertDDSToTGA
convertDDSToTGA(ddsfilename, filename)
if isfile(filename):
if type == "MESH_BIN":
Alles anzeigen
The general idea was, that importing was only done once, and tga being the base. So it flips the temporary tga image. I guess this isn't the best for all modders but that it's how I tried to solve this problem
Is there a simple way how I can turn off the flipping of the uvw in the 0.6.0 by myself?
Schau mal in mesh_util.py Zeile 275, mit # auskommentieren sollte helfen:
if material_diffuse_texture and (material_diffuse_texture.name[-3:] == "dds" or ".dds." in material_diffuse_texture.name): # DDS images are flipped because reasons
uvmap[uv[0]].data[face_index].uv1.y = 1 - uvmap[uv[0]].data[face_index].uv1.y
uvmap[uv[0]].data[face_index].uv2.y = 1 - uvmap[uv[0]].data[face_index].uv2.y
uvmap[uv[0]].data[face_index].uv3.y = 1 - uvmap[uv[0]].data[face_index].uv3.y
The format of the zip file is wrong. Blender expects for an automatic installation from a zip, what is a folder in the zip and then the plugin in this folder.
As you thought about the textures, it doesn't make sense for a modder, you need the UVW flipped for export and if I have like 120 mesh on a steam locomotive then I don't feel like doing that by hand. I don't care that the textures are upside down, I don't need them.
So please make a option to flip the UVW again during the export or include an option for the import so that the UVW does not flip during import.
As it is now, I would not (want to) use the plugin.
Hi Maik,
Thanks for the note about the .zip file. I think that I have fixed it.
Regarding the textures, the plugin can export them for you too. So if you've prepared texture A.dds and you import it then the import will flip it, but when you export it will produce a new A.tga which is a flipped version of the original A.dds that you can keep working on... or, that's how I thought it worked.
The idea of allowing un-flipping the uvs on export is a good one. I don't have much time to play with it right now but I think I might add something like that in future.
A problem with a material.
Hey guys, I've encountered this error when I export the files with this addon. Is there anybody knows how to solve it?
If I remember correctly, it just means that he cannot export + render the UI image because a texture cannot be found. Unfortunately he just do nothing then. But if you set "Textures" to "No textures" while exporting, the error does not appear, but no textures are exported either and no ui pic is created (which is usually not necessary anyway).
yeah... I only wish to use it to convert the model. I like to make textures in other ways...
Hi there, I read this thread and now I have the question if there is an updated version of the 0.6.0 plugin with the changes that where made by you all (flipping or not flipping of normal and this *.zip-folder-problem)?
No there is no updated version but eis_os described that's to do and it's easy enough to do it yourself.
*.zip-folder-problem)?
No idea that you mean.
I finally got around to making a version 0.6.1 which incorporates a "Flip V Coordinate" option at export. V coordinates therefore work as follows:
This weird handling is necessary because:
- DDS textures need to be flipped in Blender. I could not get the flip_image function within image_util.py to work like I expected (it was extremely slow and didn't actually change the way that the texture was applied to the model), so I instead flipped the UV mapping ( v = 1 - v ) on import if the texture is DDS.
I was working with version 0.6.1 and I noticed that Blender was always flipping the V coordinate on output, regardless of what I asked it to do. After a bit of digging, I've found that there seems to be a bug in version 0.6.1 - the wrong property is read at export and it always evaluates to "true" regardless of whether you've asked for V to be flipped. Version 0.6.2 (attached) fixes this bug.