ANN: OBJ model format support - Page 5

ANN: OBJ model format support

Share and discuss visual creations and creation practices like texturing, modelling and musing on the meaning of life.

Moderators: MR.D, Moderators

User avatar
Cremuss
Posts: 364
Joined: 28 Oct 2006, 21:38

Re: ANN: OBJ model format support

Post by Cremuss »

CarRepairer wrote:I only convert to triangles now when I export to obj. Even working with quads, when I mirror piece A to piece B, piece B's faces will now have CW vertex winding order while still having outward facing normals. This happens whether I scale -1 or if I use the mirror action. Flipping the normals for the piece does fix the problem in Spring but now it looks bad in Blender. I want it to look correct in both Spring and Blender. Obviously this just a minor problem and I can live with an inside-out arm and leg in Blender without any sleep lost, just hoping for a better solution one day.
well then I'm pretty sure what the problem is. I suppose you didn't reset scales values before exporting. Try Ctrl-a on your objects, select "Scale and Rotation to ObData". Then, ctrl-n again if needed. Exports. Should work :)
Kloot wrote:No, I didn't. The link correctly points to version 1.1 for me, so maybe your browser cache is just stale?
I just redownloaded it, works fine now.. ^^
Kloot wrote:To solve this I need a favor:

1. Create a model consisting of three unit-sized cube objects (call them A, B, and C)
2. Make B a child of A, and make C a child of B (A <-- B <-- C)
3. Move A to <1, 0, 0>, move B to <2, 0, 0> wrt A*, move C to <3, 0, 0> wrt B**
4. Use v1.1 of the exporter, then pastebin the .obj, .lua, and the .log

* meaning to <3, 0, 0> in global space
** meaning to <6, 0, 0> in global space
Ho yes it works this way, offsets are local in the exported metadata lua script.

So the critical key process is to move piece after parenting them which is really not my workflow and I guess not most of people's workflow.

I mean, when you do a model, you generally do one big single piece. Then you split your model into different pieces and move piece's origins (because the pieces are already in the right place !).
But if you want to parent pieces before moving them, you have to separate pieces, move piece's origins, reset pieces pos to 0,0,0, parent pieces, move pieces and find the right local offset to move pieces where they were before... wow, it's faster to write the metadata script by hand and manually calculate the local offset via subtracting child global pos to parent global pos, isn'it ?

Maybe it can be done in the exporter ? :mrgreen:
I mean, a solution could be to export local offset in two ways :
- if you have parented pieces before moving them, keep the way it actually do
- if you have parented pieces after moving them, calculate local offsets by subtracting X, Y, Z child values to parent values

PS : but after all it might be me who have an odd workflow :roll: :mrgreen:
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

(Sorry I'm not at my comp so I can't create that demo model at the moment).

I don't see why the workflow should matter. The final result is the same. I have the pieces, I set up the hierarchy, and I set up each piece's origin using center cursor. The exact same process as is done in UpSpring. If I'm missing a step please let me know, but from this point on I'd expect to export the lua and obj files that work in Spring (minus a few glitches like that mtllib junk).

Does the python script set offset equal to a "calculated midpos" rather than the "center" as defined by blender? I'm just glancing at code I don't understand but I see the word "midpos" used which doesn't sound like an origin. I'm not very familiar with python nor blender scripting, just asking. Edit: I see it uses a getLocation(). Okay I'll take some time to learn how this works so I can be of more help instead of shouting random guesses :P
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

Cremuss wrote: Ho yes it works this way, offsets are local in the exported metadata lua script.
Yeah, I just wanted to confirm the requirement of parenting objects first and moving them second.
Cremuss wrote: So the critical key process is to move piece after parenting them which is really not my workflow and I guess not most of people's workflow.

...

Maybe it can be done in the exporter ? :mrgreen:
I mean, a solution could be to export local offset in two ways :
- if you have parented pieces before moving them, keep the way it actually do
- if you have parented pieces after moving them, calculate local offsets by subtracting X, Y, Z child values to parent values

PS : but after all it might be me who have an odd workflow :roll: :mrgreen:
Problem is the exporter cannot infer which action was taken first. Blender would need to send events like "object moved" to scripts to make that decision.
CarRepairer wrote:I don't see why the workflow should matter. The final result is the same.
Not exactly. ;)
CarRepairer wrote:Does the python script set offset equal to a "calculated midpos" rather than the "center" as defined by blender? I'm just glancing at code I don't understand but I see the word "midpos" used which doesn't sound like an origin.
No, "midpos" is a property of the whole model, not of the pieces.
User avatar
Cremuss
Posts: 364
Joined: 28 Oct 2006, 21:38

Re: ANN: OBJ model format support

Post by Cremuss »

CarRepairer wrote:(Sorry I'm not at my comp so I can't create that demo model at the moment).

I don't see why the workflow should matter. The final result is the same. I have the pieces, I set up the hierarchy, and I set up each piece's origin using center cursor. The exact same process as is done in UpSpring. If I'm missing a step please let me know, but from this point on I'd expect to export the lua and obj files that work in Spring (minus a few glitches like that mtllib junk).
It works if you do step 1 - 2 - 3 -4 but will not if you do step 1 - 3 - 2 -4.

But seriously, in order to do 1 - 2 - 3 -4, you have to do a looots of moves starting from a rough 1 piece object...
Kloot wrote: Problem is the exporter cannot infer which action was taken first. Blender would need to send events like "object moved" to scripts to make that decision.
You can just make two buttons during the export asking the user what he wants.

Also, if the idea of doing that is ok to you (after all I'm ok to continue writing metadata by hand :) ) I googled a bit and found exactly what I'm asking (subtracting locations) :

Code: Select all

parent = object.getParent() 
if (parent is not None): 
   parentmat = parent.getMatrix('worldspace') 
   parentmat.invert() 
   mat = object.getMatrix('worldspace') * parentmat 
else: 
   mat = object.getMatrix('worldspace') 
# 'mat' is now the child object's true localspace matrix. 
What's happening in the code above is fairly simple: The getMatrix('worldspace') function gives the real, true worldspace matrix, taking all this odd parenting stuff into account and everything. So, we ask for that matrix from both the parent and its child, and then simply compute the difference between the two matrices. This gives you a matrix that describes the actual relationship between parent and child.
cf http://www.blender.org/forum/viewtopic. ... 6dfb75d8a0
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

Kloot wrote:CarRepairer wrote:
I don't see why the workflow should matter. The final result is the same.


Not exactly. ;)

Please help me understand why. From what I can see, each piece has a name, vertices, normals and stuff stored in the obj. In blender I define each piece's center (like origin in upspring) which shows in the lua file as an offset (either local distance from its parent or a global coordinate. Regardless, it's a triple.)

So what other piece of info are we missing that is needed for this to work?
Disregard

I'm so confused. If we have coordinates of vertices and object centers (origins) and parenting info, why is that not enough to create our data? Does Blender do something extra that messes things up depending on whether you moved the object before or after you parented it?

Edit:
(I should lern2read) The thread from Crem's post is the answer to my question - Blender DOES do something extra and annoying. But my brain kind of hurts now. Nice detective work!
Allow me to mess with your mind a bit: Load that .blend you posted, and then try moving your parent object somewhere far away. The child sphere is dragged along with it, good. Now ask the child for its localspace matrix again. You'll find that the child's localspace matrix has not changed. At this point your child's localspace matrix is not relative to the parent and not relative to the world. Your plugin now has no way to make sense of the localspace matrix. The plugin has no frame of reference for the child object.

It gets better. This is a feature, not a bug. Blender allows the child to remember its parent's inverse matrix at the time of parenting, such that the child doesn't have to alter its own local coordinates and yet still inherits motions from its new parent. Talk about having your cake and eating it too....

The bad news is that there's no Python API to directly ask the child for its outdated copy of the parent inverse matrix.
User avatar
Hobo Joe
Posts: 1001
Joined: 02 Jan 2008, 21:55

Re: ANN: OBJ model format support

Post by Hobo Joe »

Ahh, I didn't even think of resetting the LocRotScale, I always forget about that command.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

Cremuss wrote: Also, if the idea of doing that is ok to you (after all I'm ok to continue writing metadata by hand :) ) I googled a bit and found exactly what I'm asking (subtracting locations) :

...

cf http://www.blender.org/forum/viewtopic. ... 6dfb75d8a0
Ah thanks. I've updated the exporter to v1.2, now your workflow order (1 2 3 4 or 1 3 2 4) should no longer matter. Y and Z offsets are also prewritten in Spring's coordinate system.
User avatar
Cremuss
Posts: 364
Joined: 28 Oct 2006, 21:38

Re: ANN: OBJ model format support

Post by Cremuss »

perfect !

Works perfect with both two workflows.

Just a little error :

change line 100 from :

Code: Select all

self.loffsetz = objectPos]BLENDER_AXIS_Z] - parentPos[BLENDER_AXIS_Z]
to

Code: Select all

self.loffsetz = objectPos[BLENDER_AXIS_Z] - parentPos[BLENDER_AXIS_Z]

I guess that's it, thank you Kloot :-)
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

Cremuss wrote:"Scale and Rotation to ObData"
Worked, thanks!
Kloot wrote:Ah thanks. I've updated the exporter to v1.2, now your workflow order (1 2 3 4 or 1 3 2 4) should no longer matter. Y and Z offsets are also prewritten in Spring's coordinate system.
Still not working for me. The lua as-is still gives me an exploded model (hint, I did scale it up in blender at one point). Once again, when I set globalvertexoffsets = true, the model is no longer exploded, but animations are all messed up - it's as though the pieces all rotate around the midpos of the unit, rather than their own origins.

Attached is the lua and obj... hope it helps :(

Is it possible that you need to account for not only the parentmatrix.translationPart but also parentmatrix.scalePart?
screen00012.jpg
screen00012.jpg (43.81 KiB) Viewed 4070 times
Attachments
minotaur.obj.txt
(650.48 KiB) Downloaded 126 times
minotaur.lua
(1.57 KiB) Downloaded 130 times
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

CarRepairer wrote:hint, I did scale it up in blender at one point
Hint taken, version 1.3 is up. ;)
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

Success! It may be too soon to tell but think we're ready for prime time.

Thanks Kloot and Crem, great work guys!

:-)

Image

Uploaded with ImageShack.us
User avatar
d-gun
Posts: 126
Joined: 03 Jan 2010, 18:32

Re: ANN: OBJ model format support

Post by d-gun »

can you animate these or do you still have to use scripts
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

d-gun wrote:can you animate these or do you still have to use scripts
Scripts.

Kloot: A few small things. When exporting to spring metadata, it mirrors my model and I have to undo. Also, could Spring ignore the "mtllib s 1" thing that blender does instead of crashing? Also don't forget the windows line endings issue.
User avatar
Cremuss
Posts: 364
Joined: 28 Oct 2006, 21:38

Re: ANN: OBJ model format support

Post by Cremuss »

CarRepairer wrote:
d-gun wrote:can you animate these or do you still have to use scripts
Scripts.

Kloot: A few small things. When exporting to spring metadata, it mirrors my model and I have to undo. Also, could Spring ignore the "mtllib s 1" thing that blender does instead of crashing? Also don't forget the windows line endings issue.
I can confirm the mirror problem. Just invert the Y output either in metadata or in exporter script
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ANN: OBJ model format support

Post by Kloot »

CarRepairer wrote: Kloot: A few small things. When exporting to spring metadata, it mirrors my model and I have to undo.
Change line 103 from

Code: Select all

self.loffsety = localMat.translationPart()[BLENDER_AXIS_Y]
to

Code: Select all

self.loffsety = -localMat.translationPart()[BLENDER_AXIS_Y]
(I'll issue a new version later).
CarRepairer wrote:Also, could Spring ignore the "mtllib s 1" thing that blender does instead of crashing?
Spring should already ignore-and-not-crash-on such lines. Currently only missing object definitions can bring it down.
CarRepairer wrote:Also don't forget the windows line endings issue.
That has been fixed, it'll be in the next Spring bugfix release.
Super Mario
Posts: 823
Joined: 21 Oct 2008, 02:54

Re: ANN: OBJ model format support

Post by Super Mario »

Would be nice if someone created a 3do to obj file converter, so that I can remodel them without building from scratch.
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: ANN: OBJ model format support

Post by CarRepairer »

Kloot wrote:CarRepairer wrote:
Also, could Spring ignore the "mtllib s 1" thing that blender does instead of crashing?


Spring should already ignore-and-not-crash-on such lines. Currently only missing object definitions can bring it down.
Current version or next version? It still crashed for me but maybe I don't have the latest 0.82. I'll check again.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: ANN: OBJ model format support

Post by Neddie »

Super Mario wrote:Would be nice if someone created a 3do to obj file converter, so that I can remodel them without building from scratch.
I just open them in upspring and save them as obj.
Super Mario
Posts: 823
Joined: 21 Oct 2008, 02:54

Re: ANN: OBJ model format support

Post by Super Mario »

Neddie wrote:
Super Mario wrote:Would be nice if someone created a 3do to obj file converter, so that I can remodel them without building from scratch.
I just open them in upspring and save them as obj.
"upspring" Do not want to touch. Importer script for blender would be better for me.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: ANN: OBJ model format support

Post by hoijui »

are latest upspring sources available somewhere?
surely would be easy to run something like that in batch mode, if it really only needs open & save.
Post Reply

Return to “Art & Modelling”