New model utilities
Moderators: winston, another_commander
- Griff
- Oolite 2 Art Director
- Posts: 2481
- Joined: Fri Jul 14, 2006 12:29 pm
- Location: Probably hugging his Air Fryer
Re: New model utilities
Thanks for investigating, i'll see if i can coax the lighting functions from the default oolite shaders into this oxp
Wiki homepage for my OXP: http://wiki.alioth.net/index.php/Griff_Industries
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: New model utilities
New option
Download:
--preserve-material-names
. When used, the material names used in the OBJ file are retained, instead of replacing them with diffuse map names. This is more convenient and legible when using materials
or shaders
dictionaries for all materials.Download:
- Latest version (“live” link)
- The particular version described in this post
E-mail: [email protected]
- submersible
- Commodore
- Posts: 264
- Joined: Thu Nov 10, 2011 7:49 am
Re: New model utilities
Dat2ObjTex.py tells me that multiple textures are not supported. Before I go diving into the code - can anyone enlighten me, is that a fundamental problem with the conversion from Obj2DatTex ? I would really like to be able to round trip some models.
Povray Planets - Planet textures for your galaxy
-
- ---- E L I T E ----
- Posts: 607
- Joined: Wed Feb 20, 2013 1:24 am
- Location: Aboard the D.T.T Snake Charmer: My Xanadu
- Contact:
Re: New model utilities
I think when that happens, you need to fall back to Dat2Obj.py instead of Dat2ObjTex.py.submersible wrote:Dat2ObjTex.py tells me that multiple textures are not supported. Before I go diving into the code - can anyone enlighten me, is that a fundamental problem with the conversion from Obj2DatTex ? I would really like to be able to round trip some models.
- submersible
- Commodore
- Posts: 264
- Joined: Thu Nov 10, 2011 7:49 am
Re: New model utilities
[quote="Paradox"I think when that happens, you need to fall back to Dat2Obj.py instead of Dat2ObjTex.py.[/quote]
Sure - Dat2ObjTex suggests that too, however only the geometry ends up in the .obj - UV vertex attributes are lost.
Sure - Dat2ObjTex suggests that too, however only the geometry ends up in the .obj - UV vertex attributes are lost.
Povray Planets - Planet textures for your galaxy
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: New model utilities
It's just a limitation of Dat2ObjTex. For most cases, simply writing a new “usemtl” command each time the texture name changes in the DAT would probably be sufficient. In theory, this could lead to multiple non-contiguous “usemtl” commands for the same material, which might confuse some OBJ tools, but I don’t think any of our converters would generated DATs with that issue unless they got an OBJ like that in the first place.submersible wrote:Dat2ObjTex.py tells me that multiple textures are not supported. Before I go diving into the code - can anyone enlighten me, is that a fundamental problem with the conversion from Obj2DatTex ? I would really like to be able to round trip some models.
A bigger challenge would be handling the “NORMALS” and “NAMES” groups generated by Obj2DatTexNorm.
E-mail: [email protected]
- Tricky
- ---- E L I T E ----
- Posts: 821
- Joined: Sun May 13, 2012 11:12 pm
- Location: Bradford, UK. (Anarchic)
Re: New model utilities
Is there a formal specification for the .DAT file?
The output is... well... I could do with a spec list so I could code an importer . I already have one for .OBJ files (parses but data not tested, but I suspect all I would have to do is throw the data at OpenGL).
For conversion from OBJ to DAT (for Oolite), I use
Also, why the warning about having the python files in the same directory as the objects? I have them located in
The output is... well... I could do with a spec list so I could code an importer . I already have one for .OBJ files (parses but data not tested, but I suspect all I would have to do is throw the data at OpenGL).
For conversion from OBJ to DAT (for Oolite), I use
Obj2DatTexNorm.py
with --preserve-material-names
(or -m
) - I find it simpler to use in the shipdata.plistAlso, why the warning about having the python files in the same directory as the objects? I have them located in
/usr/local/bin
- no problems so far.- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: New model utilities
No, so here is an informal one.Tricky wrote:Is there a formal specification for the .DAT file?
A quirk of the format is that the parser treats commas as whitespace.
After the header (NVERTS/NFACES), the file is divided into sections, which must appear in order. The order is: VERTEX, FACES, TEXTURES, NAMES, NORMALS, TANGENTS, END. Only VERTEX and FACES are required. (END isn't actually checked for.)
The VERTEX section consists of NVERTS lines with three numbers on. These are coordinates in a left-handed coordinate system, in game metres. +X is starboard, +Y is up, +Z is forward.
The FACES section consists of NFACES lines like this:
<smooth-group> <ignored1> <ignored2> <nx> <ny> <nz> 3 <idx1> <idx2> <idx3>
The literal 3 is because the format supports non-triangular faces, but Oolite does not.
nx, ny, nz
form a face normal. This is ignored of NORMALS is present. If NORMALS is not present and smooth
is set in the shipdata entry, smooth-group
is used to group faces together in smoothing to provide a mix of smooth and sharp edges. The two ignored values (which should be integers) are historical artefacts.The TEXTURES section consists of NFACES lines like this:
<name> <uscale> <vscale> <u1> <v1> <u2> <v2> <u3> <v3>
(The number of u,v pairs must match the number of vertices in a face; as per above, this is expected to be 3.)
Each u,v pair is multiplied by uscale,vscale.
name
specifies the material to use. If it’s an integer and there’s a NAMES section, it’s treated specially.NAMES must be followed by an integer (
<nameCount>
) on the same line, and is followed by nameCount
lines. Each line is a material name.For each TEXTURES line whose
name
is an integer, the name
is used as a zero-based index into the name list. This allows names with spaces (but no commas), but it’s mainly there to save a little disk bandwidth for large models.NORMALS consists of NVERTS lines with three numbers, like VERTEX, but in this case they specify vertex normals. If NORMALS is present, the face normals and the shipdata
smooth
key are ignored. This is generally a Good Thing.TANGENTS is like normals, but specifies tangents. Of the top of my head, I think these are supposed to point in the +U direction, in the plane perpendicular to the normal vector. If TANGENTS is not present, tangents will be calculated based on face geometry and texture coordinates. This calculation is quite broken.
What warning is this?Tricky wrote:Also, why the warning about having the python files in the same directory as the objects? I have them located in/usr/local/bin
- no problems so far.
E-mail: [email protected]
- Tricky
- ---- E L I T E ----
- Posts: 821
- Joined: Sun May 13, 2012 11:12 pm
- Location: Bradford, UK. (Anarchic)
Re: New model utilities
----8<---- (Snip)JensAyton wrote:No, so here is an informal one.Tricky wrote:Is there a formal specification for the .DAT file?
This is gold, some stuff like the NAMES section I'd worked out.
Sorry, it was an instruction that I read last year from the wiki... OXP howto model :: Export the modelJensAyton wrote:What warning is this?Tricky wrote:Also, why the warning about having the python files in the same directory as the objects? I have them located in/usr/local/bin
- no problems so far.
I'm sure I've also seen the instruction that the python files need to be in the same directory as the model somewhere on this forum.
As an aside -- converting the model utilities with
/usr/bin/2to3
, allows the utils to work with python v3, again, somewhere on the forum it says that you can't use the utils with v3.If I am wrong about the above, then feel free to track me down and beat me around the head with a soggy trumble or a Billy Bass model - which ever is closest.
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: New model utilities
As I read it, that’s not so much a “warning” as one way to do it.Tricky wrote:Sorry, it was an instruction that I read last year from the wiki... OXP howto model :: Export the model
Oh, one additional note: for future-proofing, the two ignored values on face lines should be the same for every face. The existing tools use either 0 or 127 depending on tool; I suggest sticking with 0.
E-mail: [email protected]
- maik
- Wiki Wizard
- Posts: 2028
- Joined: Wed Mar 10, 2010 12:30 pm
- Location: Ljubljana, Slovenia (mainly industrial, feudal, TL12)
Re: New model utilities
Your "informal" documentation inspired me to quickly check out how to write a plugin for Google SketchUp
I just managed to read and display all .dat files that I tried (most vanilla oolite dat files and one from Griff) so if someone would like to check it out, find the code below. Note that I also needed to quickly check out how to write Ruby code, so it's not pretty
Save the code in a file called "oolite_plugin.rb" and put it into the plugin folder. (Re)Start SketchUp and it loads the plugin.
The plugin creates a menu "PlugIns" with the item "Load Oolite DAT file". It does not do any error checking nor any unit conversion. At the moment, it only reads the NVERTS, NFACES, VERTEX, and FACES sections of the file and ignores the information about normals in the faces definitions. Still, it seems to work for the models that I tried it on and seems surprisingly fast, even on the >100k Griff model.
I used SketchUp 8 (free version) on a Windows machine to test it. It probably also works on older versions and on Mac.
Please let me know if you find problems with it. Once it seems stable and robust enough I plan to extend it to also export to DAT format.
By the way, does anyone use SketchUp for Oolite work at all?
I just managed to read and display all .dat files that I tried (most vanilla oolite dat files and one from Griff) so if someone would like to check it out, find the code below. Note that I also needed to quickly check out how to write Ruby code, so it's not pretty
Save the code in a file called "oolite_plugin.rb" and put it into the plugin folder. (Re)Start SketchUp and it loads the plugin.
The plugin creates a menu "PlugIns" with the item "Load Oolite DAT file". It does not do any error checking nor any unit conversion. At the moment, it only reads the NVERTS, NFACES, VERTEX, and FACES sections of the file and ignores the information about normals in the faces definitions. Still, it seems to work for the models that I tried it on and seems surprisingly fast, even on the >100k Griff model.
I used SketchUp 8 (free version) on a Windows machine to test it. It probably also works on older versions and on Mac.
Please let me know if you find problems with it. Once it seems stable and robust enough I plan to extend it to also export to DAT format.
By the way, does anyone use SketchUp for Oolite work at all?
Code: Select all
# oolite_plugin.rb
# copyright 2013 by Maik Schulz
# licensed CC-BY-SA 3.0
# version 0.1 (April 10th, 2013)
require 'sketchup.rb'
UI.menu("PlugIns").add_item("Load Oolite DAT file") {
load_dat_file
}
def load_dat_file
chosen_dat_file = UI.openpanel "Open Oolite DAT file"
file = File.open(chosen_dat_file, "r")
mode = 0 #expect NVERTS
file.each {|line|
line = line.split("#").at(0).rstrip #remove comments and trailing white space
if mode == 0 && line[0, 6] == "NVERTS" then
@nverts = line[7, line.length - 2].to_i
@verts = Array.new
mode = 1
elsif mode == 1 && line[0, 6] == "NFACES" then
@nfaces = line [7, line.length - 2].to_i
@faces = Array.new
mode = 2
elsif mode == 2 && line[0, 6] == "VERTEX" then
mode = 3 #expect vertex lines
elsif mode == 3 && line.split(/[,\t ]+/).size == 3 then
vertex_line = line.split(/[,\t ]+/)
@verts.push(Array[vertex_line[0].to_f, vertex_line[1].to_f, vertex_line[2].to_f])
elsif mode == 3 && line [0, 5] == "FACES" then
mode = 4 #expect face lines
elsif mode == 4 && line.split(/[,\t ]+/).size == 10 then
face_line = line.split(/[,\t ]+/)
@faces.push(Array[face_line[7].to_i, face_line[8].to_i, face_line[9].to_i])
end
}
file.close
puts "loaded " + @verts.size.to_s + " vertices, " + @faces.size.to_s + " faces from " + chosen_dat_file
model = Sketchup.active_model
entities = model.entities
for n in [email protected] - 1 do
entities.add_face @verts.at(@faces.at(n).at(0)), @verts.at(@faces.at(n).at(1)), @verts.at(@faces.at(n).at(2))
end
end
- maik
- Wiki Wizard
- Posts: 2028
- Joined: Wed Mar 10, 2010 12:30 pm
- Location: Ljubljana, Slovenia (mainly industrial, feudal, TL12)
Re: New model utilities
I just tested in on my Mac, it works just the same.
Thinking further about what to do it, I plan to implement support for smooth groups next and put all the information from the .dat file that I can't use in SketchUp yet (no idea how to deal with textures for example) into attributes that get saved in SketchUp's native format so that they don't get lost. Then, saving is next with the goal to support a lossless roundtrip workflow where you can load an Oolite .dat file, save it in SketchUp format, load the SketchUp file again and then save it back in Oolite's .dat format.
Does anyone see a benefit in this? Other than me learning a little bit of Ruby and SketchUp plugin programming and brushing up on geometric math?
Thinking further about what to do it, I plan to implement support for smooth groups next and put all the information from the .dat file that I can't use in SketchUp yet (no idea how to deal with textures for example) into attributes that get saved in SketchUp's native format so that they don't get lost. Then, saving is next with the goal to support a lossless roundtrip workflow where you can load an Oolite .dat file, save it in SketchUp format, load the SketchUp file again and then save it back in Oolite's .dat format.
Does anyone see a benefit in this? Other than me learning a little bit of Ruby and SketchUp plugin programming and brushing up on geometric math?
- DaddyHoggy
- Intergalactic Spam Assassin
- Posts: 8515
- Joined: Tue Dec 05, 2006 9:43 pm
- Location: Newbury, UK
- Contact:
Re: New model utilities
We've just started using Sketchup at work - we're quite liking it - should be fun introducing it to the students.
Building Oolite models in Sketchup would be a nice-to-have.
Building Oolite models in Sketchup would be a nice-to-have.
Oolite Life is now revealed hereSelezen wrote:Apparently I was having a DaddyHoggy moment.
-
- ---- E L I T E ----
- Posts: 607
- Joined: Wed Feb 20, 2013 1:24 am
- Location: Aboard the D.T.T Snake Charmer: My Xanadu
- Contact:
Re: New model utilities
Sorry Maik, I personally use Wings3d for everything so can't test it out. If, however, you get bored and want to write one for Wings.. I would be all over it. };]maik wrote:Does anyone see a benefit in this? Other than me learning a little bit of Ruby and SketchUp plugin programming and brushing up on geometric math?
- Dr.Tripsa
- Dangerous
- Posts: 84
- Joined: Mon Apr 30, 2012 9:33 pm
- Location: In your cargo bay, eating your chips.
Re: New model utilities
now I want this as a blender plugin...
No, I'm not a Trumble... that's a speciest and offensive remark!
~munch~
What?.... I'm hungry.
~munch~
What?.... I'm hungry.