OBJ Format I/O

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
Old 06 June 2005   #1
Question OBJ Format I/O

Question regarding Silo's OBJ format I/O

Does Silo re-order vertexes? Or is it well suited for doing things like creating morph targets for other applications?

Last edited by KBOC : 06 June 2005 at 09:05 AM.
Old 06 June 2005   #2
Unfortunately Silo destroys UV info at the moment though I'm sure that will be fixed soon. I suppose you could copy the UV info from the old file into the new but that's not an ideal solution. I'd have to say that at the moment Silo isn't ideally suited to creating morphs unless you plan to map later. On the other hand it handles high poly meshes better than most other apps so in the future it could well be an excellent choice!- Baz
Old 06 June 2005   #3
Baz pretty much nailed it...Uv mapping isn't a feature of Silo right now so which Nevercenter already has shown much interest in including it in a near future release...hopefully 1.5 Also, storing MT's has not yet made it into Silo.
Patrick Noland
Old 06 June 2005   #4
I'm not so worried about UV Info. I'm worried about Vertex Order. I can save UV info to be applied back later (if needed) with UVMapper.

I'm much more concerned with the ability to make morph targets. Re-ordered verts will prevent this from working. I just installed the learning edition, so I'll test it out on some low-res meshes... see how it goes.

I'm looking at scaling as well, and there appears to be no way that I can see (please correct me if this is wrong) to do a precision scale. What I do in Rhino is I'll import a mesh and scale it up from the world center by a factor of 20, do my work, then scale it back down to where it's supposed to be for application. This is true for models I'm making as well as morph targets for Poser.

What it looks like right now, is any work I do in Silo will have to go through Rhino first, scaled up, then back down after I'm done.
Old 06 June 2005   #5
Yes vert order is preserved correctly and you can scale using the Numerical editor. There is no option to automatically scale on import and export. - Baz
Old 06 June 2005   #6
Baz, please tell me how to scale up numerically... I'm looking through all the options and I can't seem to figure it out...

Damn... I haven't had this much fun with a modeller since the Rhino Beta!!!
Old 06 June 2005   #7
NM, found it!
Old 06 June 2005   #8
A little update, I did test it out on a Poser filtered OBJ file, and it works perfectly.
Old 06 June 2005   #9
Side note to all that, SILO will destroy UV cordinates only if new geometry is added to a mesh...

For some strange reason it cannot interpolate new coordinates yet, next version is gonna have it all sorted out, I believe, it is time of the year for adding UV mapping features anyways !
"God be between you and harm in all the empty places where you must walk." Sheridan to Zeta Squadron Babylon 5

Old 06 June 2005   #10
Speaking of .obj output... I posted this in the development thread, but didn't see any response...


Any chance of improving Silo's .obj output? Currently (as of demo version 1.4x), it looks like the program just outputs poly info 'as it finds it' and doesn't bother using the tables ability of the .obj format. Here's an example of what I mean...

~~ snip ~~
f 1/9 47/10 49/11 8/12
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 10/13 117/14 115/15 4/16
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 192/17 200/18 12/19 11/20
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 79/21 80/22 82/23 81/24
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 224/25 230/26 167/27 17/28
vt 0 0
vt 0 0
vt 0 0
vt 0 0
f 134/29 140/30 22/31 21/32

~~ snip ~

...as you can see, texture coordinates ('vt' records) are written out for EVERY vertex of EVERY facet - this is a huge waste of file space. Everyone of those 'vt 0 0' records could be replaced with ONE record, with the facet records updated to point to the correct reference.

In this example test-case (less than 5k polygons), the filesize was 947k, re-written to consolidate all of those (duplicate) texture coordinates, the file dropped to 647k.

I'd note that this was a special case, where there wasn't any actual UV-mapping, so all the coordinates were '0 0', but in a typical model, each vertex would have 3-5 (or more) polygons sharing that vertex (and UV coordinates), so the condition applies to those files as well. I'd also note that this was a fairly trivial mesh (less than 5k polys) - when you get up in the tens of thousands (or worse, hundreds of thousands) of polygons, this becomes a real issue.

I hadn't looked closely to see if this is an issue with vertex ('v') and/or normal ('vn') records yet, but these records can (and should) use the look-up tables as well, eliminating any duplicates.

Anyway, I've only just started playing around with Silo and it looks very promising - thanks for listening and bringing us yet another tool.

- Keith

...this may be slightly off-topic, but seems related enough to be interesting to anyone using Silo for .obj output.


- Keith
Old 06 June 2005   #11
Very related. The OBJ format imho has classically been the best exchange format for meshes. (but I've never used fbx so I can't speak for it)... any features that OBJ has that Silo takes advantage of is a good thing.
Old 06 June 2005   #12
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 02:27 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.