Oolite Bulletins

Posted: **Mon Jul 16, 2012 8:44 pm**

Thanks for investigating, i'll see if i can coax the lighting functions from the default oolite shaders into this oxp

Posted: **Mon Jul 16, 2012 9:26 pm**

New option --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

Python 2.7 required.

Posted: **Mon Apr 01, 2013 1:55 am**

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.

Posted: **Mon Apr 01, 2013 2:08 am**

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.

I think when that happens, you need to fall back to Dat2Obj.py instead of Dat2ObjTex.py.

Posted: **Mon Apr 01, 2013 7:14 am**

[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.

Posted: **Mon Apr 01, 2013 8:45 am**

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.

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.

A bigger challenge would be handling the “NORMALS” and “NAMES” groups generated by Obj2DatTexNorm.

Posted: **Sun Apr 07, 2013 11:35 pm**

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 Obj2DatTexNorm.py with --preserve-material-names (or -m) - I find it simpler to use in the shipdata.plist

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.

Posted: **Mon Apr 08, 2013 7:48 am**

Tricky wrote:
Is there a formal specification for the .DAT file?

No, so here is an informal one.

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.

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.

What warning is this?

Posted: **Tue Apr 09, 2013 12:12 am**

JensAyton wrote:
Tricky wrote:
Is there a formal specification for the .DAT file?
No, so here is an informal one.

----8<---- (Snip)

This is gold, some stuff like the NAMES section I'd worked out.

JensAyton wrote:
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.
What warning is this?

Sorry, it was an instruction that I read last year from the wiki...

OXP howto model :: Export the model

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.

Posted: **Tue Apr 09, 2013 6:59 am**

Tricky wrote:
Sorry, it was an instruction that I read last year from the wiki... OXP howto model :: Export the model

As I read it, that’s not so much a “warning” as one way to do it.

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.

Posted: **Wed Apr 10, 2013 1:54 am**

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?

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

Posted: **Sun Apr 14, 2013 6:40 pm**

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?

Posted: **Sun Apr 14, 2013 7:45 pm**

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.

Posted: **Sun Apr 14, 2013 7:47 pm**

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?

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. };]

Posted: **Sun Apr 14, 2013 9:09 pm**

now I want this as a blender plugin...

Oolite Bulletins

New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities

Re: New model utilities