Teaser

[JensAyton]

So, I’ve been playing around with a tool:

[Star Gazer]

now, that's neat...!

[Murgh]

wait! I hadn't looked up 'anisotropic' before voting.

well, whatever it is, I want one.
so you just slip a .dat in there with its corresponding textures and voila a preview machine? or more/else to the story?

[aegidian]

That's a really tempting 'customize' button.

[JensAyton]

Currently, it’s little more than a previewer. It can open .dat files, and write .dat files. The only editing it can do is to recalculate normals and flip the winding direction of the faces, neither of which is actually useful.

The next step is importing obj files, and possibly Meshworks and Wings3D format. That makes it a visual file converter.

I also intend to make it useful for placing subentities and exhaust, setting some parameters and exporting simple OXPs.

A longer term project is creating a binary file format for Oolite models. This will be flexible and allow things like mixing smoothed and unsmoothed polygons in the same file (which will require changing how Oolite thinks about meshes), multiple sets of materials (so that skin variants can share the same mesh), store stuff like exhaust plumes with the mesh and possibly allow the inclusion of subentities in the parent entity’s file. It should also be faster to load (less interpretation required).

It also provides me a testbed for certain kinds of graphics twiddling… like pimped up textures, coming soonish in a version of Oolite somewhere. ;-)

Incidentally, if anyone feels like making an app icon, say a raytraced Behemoth in a snazzy Star-Trek like space dock, or some better tool icons, there’s some space free in the about box. :-p

[aegidian]

That all sounds cool except for this:

A longer term project is creating a binary file format for Oolite models.

(my emphasis)

I'm opposed to expressing any part of Oolite's data (except pictures or textures) in a file format that's not human-readable. I know that this chokes the speed at which data can be read, but I consider this a minor problem compared against the advantages of having files that are easy for users and developers to tinker with.

If there are other reasons to use a binary file format I'd ask to consider using having Oolite compile it from a human readable format and cache the results in files in Application Support/Oolite (in the same way that Quake (1) stored GL meshes having compiled them from the original models).

[JensAyton]

I’ll keep that in mind.

[Murgh]

well, looks like a brill previewer. any plans to have it tumble and move around like in Wings? visual axes if it's to be used to position things..?

will it all tie up to the oolite replay-player?

if I see that cool space dock, I'll let you know.

[JensAyton]

Currently you can rotate the object on two axes (note selected Rotate tool), move the light around and zoom in/out. I’ll probably switch to a better “virtual trackball” kind of thing at some point. Positioning stuff will probably snap to faces/edges/vertices, if I can get the analytical geometry right. :-p

Oh, and I intend to have a mirror function: select a subentity or exhaust plume, click a check box and you’ve got a duplicate on the other side.

[JensAyton]

Hey, Giles, is there a particular reason for generating the noise in the “blur” texture on the fly rather than having it in the image? I ask because it complicates the implementation of mip-mapping… for now I’ll just not mip-map that particular texture.

Side note: I’m setting it up so mip-mapping and anisotropic filtering (if available) are used only if Reduced Detail is off. What else does that do, anyway? :-)

[aegidian]

Hey, Giles, is there a particular reason for generating the noise in the “blur” texture on the fly rather than having it in the image? I ask because it complicates the implementation of mip-mapping… for now I’ll just not mip-map that particular texture.

It was just the easiest way to do it. Anyhoo the blur's noise almost certainly should not be mip-mapped anyway.

[winston]

A longer term project is creating a binary file format for Oolite models.

If you do, bear in mind that PowerPC is big endian and i386 and amd64 is little endian (and of course, amd64 has some longer types). Other than that, I strongly agree on aegidian about binary formats.

[JensAyton]

Hey, Giles, is there a particular reason for generating the noise in the “blur” texture on the fly rather than having it in the image? I ask because it complicates the implementation of mip-mapping… for now I’ll just not mip-map that particular texture.

It was just the easiest way to do it. Anyhoo the blur's noise almost certainly should not be mip-mapped anyway.

A guassian-distribution blur will probably look better with mip-mapping… I’ll try it. Once I get around some other issues: the mip-mapped texture loader from the tool (Dry Dock) uses a Tiger-only method and chokes on alpha channels. Other than that, it works fine…

And yeah, when thinking about binary formats I was keeping endian issues in mind. At this point, not doing so would be silly even in a Mac-only project. :-)

[JensAyton]

Oh, while digging around in the texture code I’ve noticed that the app makes a redundant copy of texture data and keeps it around. glTexImage2D() copies data (unless using certain extensions to stop it), so the app’s copy isn’t needed.

[Murgh]

it can already browse through 'sealed' oxp's, with .dats and textures in separate folders and everything?

give a word when you can let other people try your Dry Dock.

and BTW, Giles just gave me a Behemoth Wings original, so I'd like a go at crafting an icon if the commission is still out there.