[15:06:48] <[1uP]CarRepairer> is there new spring? is there assimp?
[15:07:08] <[1uP]CarRepairer> ive been waotong literally over 5 years for this
[15:07:12] <spliff> Car: yes and yes
[15:07:24] <spliff> though Assimp hasn't had much testing
[15:07:43] <[1uP]CarRepairer> oh there will be testing
[15:07:44] <spliff> it's probably broken until 84.0 tbh
[15:08:06] <[1uP]CarRepairer> there will be much testing
[15:08:07] <spliff> but pls test all you can
[15:08:50] <[1uP]CarRepairer> so blender export to collada then what
[15:09:13] <spliff> then tell your unit script to use the collada file
[15:09:33] <spliff> ie object3D = unit.dae
[15:09:53] <spliff> then cross fingers
[15:10:00] <[1uP]CarRepairer> height?
[15:10:15] <spliff> it should work even without a metafile, it guesses height
[15:11:01] <[1uP]CarRepairer> k
[15:11:44] <[1uP]CarRepairer> i will try right now
[15:11:47] <[1uP]CarRepairer> are you here a while?
[15:11:57] <spliff> yes
5:12:14] <[1uP]CarRepairer> this could be at turning point in video game history
[15:12:26] <[1uP]CarRepairer> i'm doing my best to contain myself
[15:12:32] <[LCC]KingRaptor[0K]> spliff, did assimp end up having the model scaling?
[15:12:45] <spliff> no, jK was opposed to it
[15:13:07] <spliff> I would need assimp to prescale the model and that's hard
[15:13:14] <spliff> not impossible though
[15:13:26] <spliff> just that normals and shit need recalculating'
[15:13:40] <[1uP]CarRepairer> brb
[15:13:42] ** [1uP]CarRepairer left the channel( Quit ).
[15:14:02] <spliff> CarRepairer: you should look in assimp announcement thread for some details of metafile etc
[15:14:21] ** [1uP]CarRepairer joined the channel.
[15:14:26] <spliff> CarRepairer: you should look in assimp announcement thread for some details of metafile etc
[15:14:36] <spliff> http://springrts.com/phpbb/viewtopic.php?p=463265#p463265
[15:14:58] <spliff> I don't think Model-detail exists anymore though
[15:15:09] <[1uP]CarRepairer> i just realized odds are my mod will be broken in .83
[15:15:11] <spliff> as a LogSection
[15:15:17] <[1uP]CarRepairer> so this won't be a smooth transition
[15:16:09] <[1uP]CarRepairer> ok so far so good
[15:16:15] <[1uP]CarRepairer> it runs, sort of
[15:16:21] <[1uP]CarRepairer> now.. um i don't have blender installed
[15:16:26] <[1uP]CarRepairer> so i'll get right on that
[15:19:06] <[1uP]CarRepairer> aw crap i'm running spring .82
[15:19:44] <[1uP]CarRepairer> weird
[15:20:03] <[1uP]CarRepairer> spring is still .82
[15:20:09] <[1uP]CarRepairer> even though i installed .83
[15:20:19] <[1uP]CarRepairer> the hell
[15:23:44] <[1uP]CarRepairer> ok .83 runs. looks like obj still works
[15:23:54] <[1uP]CarRepairer> i thought you were removing the kloot obj pipeline
[15:24:26] <[1uP]CarRepairer> spliff
[15:24:47] <spliff> i did, he put it back
[15:24:53] <[1uP]CarRepairer> ok
[15:25:48] <[1uP]CarRepairer> man i dont know how to use this new blender, lol
[15:26:00] <spliff> 2.5? i luv it
[15:26:07] <[1uP]CarRepairer> its 2.6 now
[15:26:43] <[1uP]CarRepairer> how to change to perspective view
[15:27:00] <[1uP]CarRepairer> ok this will take me a while
[15:27:04] <[1uP]CarRepairer> i'll get back to you with my results
[15:36:52] <[1uP]CarRepairer> spliff: unit shows up but it's mostly red
[15:36:58] <[1uP]CarRepairer> and turned 90degrees
[15:37:04] <spliff> that's reversed teamcolor
[15:37:05] <[1uP]CarRepairer> i didn't add a texture 2
[15:37:07] <[1uP]CarRepairer> k
[15:37:09] <[1uP]CarRepairer> what do i do?
[15:37:26] <spliff> what type of textures are you using (ie, DDS)?
[15:37:31] <[1uP]CarRepairer> lemme see
[15:37:39] <[1uP]CarRepairer> i downloaded a blender from web
[15:37:45] <[1uP]CarRepairer> blender model
[15:37:52] <spliff> no TEXTURE
[15:37:53] <[1uP]CarRepairer> it's a jpg
[15:38:14] <spliff> hmm, you using OBJ or DAE?
[15:38:39] <spliff> kloots obj code is different to assimp
[15:38:56] <[1uP]CarRepairer> blender exported to dae
[15:39:32] <spliff> i'd say your jpg was setup for S3O. you have 2 choices:
[15:39:47] <[1uP]CarRepairer> actually
[15:39:49] <spliff> 1.) reverse the black/white levels in the alpha channel
[15:39:49] <[1uP]CarRepairer> wait
[15:39:53] <[1uP]CarRepairer> i did "unpack image"
[15:39:57] <[1uP]CarRepairer> but i might not have saved it
[15:40:01] <[1uP]CarRepairer> the image was internal
[15:40:06] <spliff> 2.) reverse teamcolor in the metafile for the model
[15:40:17] <[1uP]CarRepairer> no, my jpg was not setup for s3o, this is a model downloaded from web
[15:40:21] <[1uP]CarRepairer> gimme a sec, sorry
[15:40:42] <spliff> assimp doesn't read the texture out of model yet, it must go in unittextures/
[15:40:47] <[1uP]CarRepairer> yes
[15:40:52] <[1uP]CarRepairer> it's in unittextures. i clicked on unpack
[15:41:03] <[1uP]CarRepairer> and then i clicked "replace image"
[15:41:08] <[1uP]CarRepairer> and browsed to the image in unittextures
[15:41:21] <[1uP]CarRepairer> and saved
[15:41:26] <[1uP]CarRepairer> and it appears fine in blender
[15:41:28] <[1uP]CarRepairer> then export to collada
[15:41:41] <spliff> open image in gimp/photoshop and tell me if if teamcolor appears opaque or transparent?
[15:42:01] <[1uP]CarRepairer> i never added a teamcolor
[15:42:01] <spliff> oh wait... JPG has no alpha
[15:42:05] <[1uP]CarRepairer> ok
[15:42:10] <[1uP]CarRepairer> i'll rectify this problem then
[15:42:12] <[1uP]CarRepairer> and make it png
[15:42:16] <spliff> no
[15:42:27] <spliff> the problem must be something else
[15:42:37] <[1uP]CarRepairer> i want it as a png anyway
[15:42:44] <spliff> an opaque texture should just work, even jpg
[15:42:52] <[1uP]CarRepairer> ok
[15:43:02] <spliff> is the whole model red or just parts?
[15:43:07] <[1uP]CarRepairer> whole
[15:43:26] <spliff> any errors in infolog?
[15:43:46] <spliff> try turning on LogSections = Texture,Model
[15:44:09] <spliff> and you'll see messages regarding texture loading and model
[15:44:31] <[1uP]CarRepairer> i don't understand the "try turning on" sentence
[15:44:48] <spliff> in .springrc add that as a line
[15:44:59] <spliff> LogSections = Texture,Model
[15:45:02] <[1uP]CarRepairer> changing to png fixed it
[15:45:07] <[1uP]CarRepairer> works great now
[15:45:10] <spliff> really?
[15:45:18] <[1uP]CarRepairer> note that i named the png same as dae object
[15:45:36] <[1uP]CarRepairer> now i have a 90 degree issue
[15:45:38] <spliff> ah! that's important!
[15:45:44] <[1uP]CarRepairer> is it?
[15:45:48] <[1uP]CarRepairer> good thing i mentioned it
[15:46:04] <[1uP]CarRepairer> it was named "oldbicktexture" or something, when it was packed into the model
[15:46:04] <spliff> yes, it searches for textures based on unit name
[15:46:09] <[1uP]CarRepairer> ok cool
[15:46:18] <[1uP]CarRepairer> how to solve 90 degree issue?
[15:46:22] <[1uP]CarRepairer> i can turn it in blender
[15:46:26] <[1uP]CarRepairer> but is there another way
[15:46:37] <spliff> yes, in a metafile you can rotate
[15:46:47] <[1uP]CarRepairer> prefer no metafiles
[15:46:51] <spliff> see example in that thread I linked
[15:46:59] <spliff> then rotate in blender
[15:47:03] <[1uP]CarRepairer> prefer less complex solutions
[15:47:07] <[1uP]CarRepairer> ok
[15:47:22] <[1uP]CarRepairer> i could also turn the unit in the script, maybe
[15:47:31] <spliff> i don't think so
[15:47:51] <[1uP]CarRepairer> if i have a root piece
[15:47:54] <[1uP]CarRepairer> i could rotate it
[15:47:58] <spliff> spring has fixed concept of unit direction
[15:48:04] <[1uP]CarRepairer> jK has stated that's a bad idea though
[15:48:12] <[1uP]CarRepairer> true
[15:48:18] <spliff> just try it
[15:48:29] <[1uP]CarRepairer> i don't have a script set up
[15:48:41] <spliff> you'll know something went bad if things start rotating around the wrong axis
[15:48:56] <spliff> i mean in blender
[15:49:03] <spliff> rotate root there
[15:50:39] <[1uP]CarRepairer> well
[15:50:44] <[1uP]CarRepairer> first i must relearn blender :)
[15:50:49] <[1uP]CarRepairer> but i'm glad it's progressing
[15:51:00] <[1uP]CarRepairer> i haven't even used blender 2.4 in over a year
[15:51:02] <[1uP]CarRepairer> so it's just as well
[15:52:08] <[1uP]CarRepairer> aw crap
[15:52:12] <[1uP]CarRepairer> this model has multiple images
[15:52:16] <[1uP]CarRepairer> i hate that
[15:52:26] <spliff> yup, not supported by spring
[15:52:36] <[1uP]CarRepairer> yeah
[15:52:41] <[1uP]CarRepairer> that's what cremuss used to do
[15:52:56] <[1uP]CarRepairer> and i had to figure out how to put everything in a new image and remap
[15:52:59] <[1uP]CarRepairer> it was a horrible pain
[15:53:03] <spliff> is supported by assimp internally but then spring can't use the other textures
[15:53:28] <[1uP]CarRepairer> so to add teamcolor
[15:53:31] <[1uP]CarRepairer> is it same as s3o?
[15:53:34] <[1uP]CarRepairer> or reverse?
[15:53:46] <spliff> it's opposite of s3o, teamcolor is the transparent parts
[15:54:06] <spliff> makes it easier to work with opaque textures
[15:55:15] <[1uP]CarRepairer> awesome
[15:55:20] <[1uP]CarRepairer> thank you for doing that
[15:55:27] <[1uP]CarRepairer> now what sucks is a lot of these online models use multiple textures
[15:55:32] <[1uP]CarRepairer> so i predict a lot of pain in the future
[15:55:40] <spliff> there is a switch to get old behaviour but you need a metafile for that
[15:55:44] <[1uP]CarRepairer> but it will still be better than the old days of upspring
[15:55:50] <[1uP]CarRepairer> no need
[15:55:54] <[1uP]CarRepairer> new behavior is superior
[15:56:52] <spliff> i could prbably add multitexture support to spring, it just means grouping rendering by pieces instead of whole models
[15:57:14] <spliff> also we need a way to map textures to pieces instead of models
[15:57:20] <[1uP]CarRepairer> how soon can you do this?
[15:57:31] <spliff> maybe unittextures/modelname/piecename.png
[15:57:32] <[1uP]CarRepairer> i am convinced there is nothing you can't do now
[15:57:57] <spliff> it all depends, spring rendering system is hard to change
[15:58:16] <spliff> not impossible, just hard. though this change might not be too hard
[15:59:03] <spliff> i won't promise any specific time, but i'll have a look at it
[15:59:40] <spliff> at the moment i'm still working on making spring run on my x1950xt
[15:59:48] <[1uP]CarRepairer> do you know how to make one piece the parent of another?
[15:59:50] <[1uP]CarRepairer> in blender
[15:59:58] <spliff> which is a time-consuming pain in the arse
[16:00:10] <spliff> yes, CTRL-P I think
[16:00:32] <spliff> i can't remember if you select the parent first or the child
[16:00:49] <spliff> there's some YouTube tuts on it though
[16:00:57] <spliff> that's how I learnt how
[16:02:09] <spliff> there's also a UI part that shows hirearchy and I think you can drag-drop and copy-paste in it
[16:02:10] <[1uP]CarRepairer> doesnt work
[16:02:18] <[1uP]CarRepairer> i'm in the outliner
[16:02:48] <spliff> try selecting both at once then, the order you select them matters
[16:03:09] <[1uP]CarRepairer> anything-P doesn't work
[16:03:12] <[1uP]CarRepairer> i remember it worked in old blender
[16:03:23] <[1uP]CarRepairer> oh blender!
[16:03:25] <spliff> http://wiki.blender.org/index.php/Doc:Manual/Modeling/Objects/Groups_and_Parenting
[16:03:30] <[1uP]CarRepairer> the more you change the more you stay the same
[16:03:46] <spliff> actually: http://wiki.blender.org/index.php/Doc:2.5/Manual/Modeling/Objects/Groups_and_Parenting
[16:04:05] <spliff> To parent objects, select at least two objects (Select the child objects first, and select the parent object last), and press CtrlP.
[16:06:15] <[1uP]CarRepairer> that doesnt work anymore
[16:06:20] <[1uP]CarRepairer> i find the new way, from your link
[16:06:28] <[1uP]CarRepairer> use the "constraint"
[16:06:32] <[1uP]CarRepairer> make it "child of"
[16:06:42] <[1uP]CarRepairer> although i don't think i like that
[16:07:18] <[1uP]CarRepairer> it doesnt show right on the hierarchy
[16:10:51] <[1uP]CarRepairer> ok finally got it
[16:10:53] <[1uP]CarRepairer> ctrl p is a lie
[16:14:47] <[1uP]CarRepairer> spliff, do textures still need to be square?
[16:15:03] <spliff> don't know.
[16:15:57] <spliff> probably should be multiple of 2, but i don't think it has to be square
[16:16:39] <spliff> i think it's just common to go 256x256, 512x512 etc. might be faster for hardware
[16:16:53] <[1uP]CarRepairer> you need to be the expert on this
[16:16:59] <[1uP]CarRepairer> until now, s3o required square
[16:17:11] <spliff> sorry, try jk or kloot
[16:17:15] <[1uP]CarRepairer> [LCC]jK
[16:19:53] <spliff> just try it, i don't recall seeing anything in the texture code requiring squareness
[16:20:20] <spliff> it's more likely to be related to limits in old hardware and cache optimisation
[17:05:06] <[1uP]CarRepairer> spliff
[17:05:12] <[1uP]CarRepairer> only the base object is rotated
[17:05:16] <[1uP]CarRepairer> the child object is not
[17:05:18] <[1uP]CarRepairer> why
[17:05:36] <spliff> are you sure the child is linked?
[17:06:03] <[1uP]CarRepairer> linked i dunno
[17:06:36] <[1uP]CarRepairer> do i have to do something special to each child object?
[17:07:16] <spliff> I don't think so, the outline should show the child indented up the parent
[17:07:26] <[1uP]CarRepairer> yes
[17:07:27] <[1uP]CarRepairer> it does
[17:07:36] <[1uP]CarRepairer> but the child object is shown correctly rotated
[17:07:39] <[1uP]CarRepairer> while the parent object is not
[17:08:25] <[1uP]CarRepairer> i'll show you a screenshot
[17:08:27] <[1uP]CarRepairer> it's a windmill
[17:09:05] <spliff> you might have to ensure the child rotation is reletive to the parent, not the world
[17:09:20] <spliff> there's a way to do that in blender
[17:09:26] <[1uP]CarRepairer> :/
[17:09:50] <spliff> or maybe it's the other way around
[17:12:06] <spliff> For non-inverse-mode press ? ShiftCtrlP instead. This creates an alternative parent-child-relationship where child-objects exist entirely in parent coordinate system. This is the better choice for CAD purposes for example. 
[17:12:29] <[1uP]CarRepairer> sigh
[17:12:31] <[1uP]CarRepairer> hold on
[17:12:45] <spliff> sorry, i did my own testing so long ago
[17:13:27] <spliff> try Alt-P on the child then "Clear Parent Inverse"
[17:13:34] <spliff> "Places the children with respect to the parent as if they were placed in the Global reference. This effectively clears the parent's transformation from the children. For example, if the parent is moved 10 units along the X axis and Clear Parent Inverse is invoked, any selected children are freed and moved -10 units back along the X axis. The "Inverse" only uses the last transformation; if the parent moved twice, 10 units each time for a total of 20 units, then the "Inverse" will only move the child back 10 units, not 20. "
[17:14:29] <[1uP]CarRepairer> i want to see where this special altP is in the menu
[17:14:34] <[1uP]CarRepairer> i found where parent is
[17:14:39] <[1uP]CarRepairer> but not the alt Panret
[17:14:41] <[1uP]CarRepairer> parent
[17:14:54] <spliff> don't know, i'm just reading wiki
[17:17:20] <spliff> actually Alt-P might release the children entirely, I'm not sure how to set Inverse" mode directly
[17:18:01] <spliff> maybe just Shift-Ctrl-P already parented objects
[17:18:16] <[1uP]CarRepairer> when i did clear parent inverse, the object disappears
[17:18:35] <spliff> it may have just moved somewhere else
[17:18:45] <[1uP]CarRepairer> there has to be an easier way
[17:18:59] <spliff> or been rescaled
[17:19:13] <spliff> try the Shift-Ctrl_p key
[17:19:51] <[1uP]CarRepairer> k
[17:20:00] <spliff> or Alt-P -> Clear Parent then Shift-Ctrl-P to rebind with relative coords
[17:23:27] <[1uP]CarRepairer> "make parent without inverse" causes the object to flip around
[17:24:17] <spliff> because parent is rotated maybe
[17:24:33] <spliff> so it's now rotating the child?
[17:24:52] <spliff> do you have the transform properties thing visible?
[17:25:09] <spliff> so you can see the X,Y,Z rotation?
[17:27:29] <spliff> you might have to rotate the child relative to the parent
[17:27:39] <[1uP]CarRepairer> darnit
[17:27:44] <[1uP]CarRepairer> they are both rotated the same way
[17:27:52] <[1uP]CarRepairer> when i right click on them
[17:27:58] <spliff> so the child would be rotated twice then
[17:28:45] <[1uP]CarRepairer> so let's start over
[17:28:48] <[1uP]CarRepairer> what do i need to do
[17:28:51] <spliff> ie, parent rotation + child rotation = apparent rotation
[17:28:55] <[1uP]CarRepairer> ctrl shift p, then rotate?
[17:30:15] <spliff> sounds right
[17:30:42] <spliff> i'd help more but blender isn't compiling here
[17:31:18] <[1uP]CarRepairer> ok
[17:31:23] <[1uP]CarRepairer> why do you need to compile it?
[17:32:49] <spliff> gentoo. i need to compile everything
[17:33:06] <[1uP]CarRepairer> ah
[17:33:14] <[1uP]CarRepairer> no matter what i try, it's still not rotated the way i want
[17:33:17] <[1uP]CarRepairer> making screenie
[17:33:19] <spliff> i just turned off ffmpeg support, that may fix it
[17:34:40] <[1uP]CarRepairer> http://i.imgur.com/CABL5.jpg
[17:34:45] <[1uP]CarRepairer> camera is beneath the ground
[17:34:49] <[1uP]CarRepairer> so ground is invisible
[17:34:58] <[1uP]CarRepairer> note the rotors are correct
[17:35:03] <[1uP]CarRepairer> and the windmill tower is rotated
[17:35:16] <[1uP]CarRepairer> rotors are child of tower
[17:35:25] <[1uP]CarRepairer> tried all the different parenting techniques
[17:35:28] <[1uP]CarRepairer> it always looks like this
[17:35:49] <spliff> and you're exporting as collada?
[17:36:22] <[1uP]CarRepairer> yep
[17:36:46] <spliff> can u pastebin the collada file?
[17:36:50] <[1uP]CarRepairer> one sec
[17:38:01] <spliff> and infolog.txt with LogSections = Model,Piece
[17:38:59] <spliff> nice, disabling ffmpeg let blender build
[17:39:13] <spliff> email the blend file to spliff@warriorhut.org
[17:39:20] <[1uP]CarRepairer> http://pastebin.com/cbx0hwHU
[17:46:11] <spliff> one problem i can see already is you have a scaled object. Everything needs to have a scale of 1 which means you have to tell blender to rescale the mesh rather than the node
[17:46:39] <spliff> that's why the blades are smaller than the tower
[17:47:24] <spliff> there is a way to apply a node transformation to the mesh but I forget it
[17:48:07] <spliff> i think it's in the menu that comes up when you click an object
[17:48:11] <[1uP]CarRepairer> is it..
[17:48:17] <[1uP]CarRepairer> object > apply > rotation and scale
[17:48:29] <spliff> yup, i'd say so
[17:49:12] <[1uP]CarRepairer> that worked
[17:49:15] <[1uP]CarRepairer> excellent
[17:49:22] <[1uP]CarRepairer> now to rotate the root piece 90
[17:53:45] <spliff> you can see why I wanted scale support in the engine. it would avoid some of these issues
[17:54:05] <spliff> wouldn't solve the rotation issue though
[17:55:28] <spliff> yo, send me that blend file
[17:57:01] <[1uP]CarRepairer> you still need it?
[17:59:17] <[1uP]CarRepairer> it's all resolved now
[17:59:18] <spliff> yeah, i wanna see your transforms and hierarchy
[17:59:22] <[1uP]CarRepairer> ok
[17:59:23] <[1uP]CarRepairer> hold on
[17:59:25] <spliff> even the rotation?
[17:59:56] <spliff> so applying the scale/rotation fixed everything?
[18:00:17] <[1uP]CarRepairer> yes
[18:00:22] <[1uP]CarRepairer> you still want it?
[18:00:26] <spliff> you better check the blades rotate around the correct axis still
[18:00:34] <[1uP]CarRepairer> ok
[18:00:39] <spliff> you got a script on it?
[18:00:44] <[1uP]CarRepairer> nope not yet
[18:00:48] <[1uP]CarRepairer> but i'll try all this stuff tomorrow
[18:00:54] <[1uP]CarRepairer> in the meantime, it looks correct
[18:01:10] <spliff> well that's a start
[18:01:31] <[1uP]CarRepairer> http://i.imgur.com/0GtLX.jpg
[18:01:56] <[1uP]CarRepairer> disregard the greenness, that's just because it's selected
[18:02:16] <[1uP]CarRepairer> i'll continue tomorrow with script
[18:02:22] <[1uP]CarRepairer> thanks for the assimp
[18:02:50] <spliff> i don't think there's any easy way to handle all this. basically you have 3 types of rotation: 1.) Rotations around global coords, 2.) Rotation around parent(s), 3.) Rotation/position of vertices/mesh inside the child.
[18:03:28] <spliff> it'll take some practice to get the right combination
[18:04:35] <spliff> i think blender uses global coords by default until you tell it not to
[18:05:12] <spliff> but then spring thinks those global transforms are relative to the parent
[18:11:19] <[1uP]CarRepairer> its not much trouble to select all and apply rot/scale
[18:11:57] <spliff> yes but as I said that doesn't guarentee your children will rotate around the correct axis
[18:13:15] <[1uP]CarRepairer> ok, i will see how the animations work tomorrow
[18:13:20] <spliff> it may be that your "mesh" is skewed relative to its "node"/"object". spring objects rotate around node coords, not mesh coords
[18:14:12] <[1uP]CarRepairer> but these issues you describe are very familiar to the issues with kloot's obj
[18:14:15] <spliff> so it's possible for an object to look fine but in fact be totally fucked when you animate
[18:14:22] <[1uP]CarRepairer> which eventually hit a wall
[18:14:35] <spliff> i think kloots obj has the option to use global coords
[18:14:51] <spliff> it may even use global coords by default
[18:15:19] <spliff> could be wrong though
[18:15:58] <[1uP]CarRepairer> so if tomorrow i try to animate and it doesnt rotate right, what will i need to do?
[18:20:09] <spliff> you'll need to ensure the mesh in any child object lines up with its bounding box along the axis you wish to rotate around
[18:20:54] <spliff> remember, it's the hidden box that will actually be rotating, it just takes the mesh along with it
[18:21:18] <spliff> so if the mesh is crooked to rotation will be weird
[18:21:29] <[1uP]CarRepairer> can you explain the mesh thing better
[18:21:30] <spliff> *to* -> the
[18:22:21] <spliff> well, "up" on your mesh should be the same direction as "up" on it's "node" (the box around the mesh you see when you select it).
[18:22:49] <spliff> which I think is either Z or Y,
[18:23:34] <spliff> then the "node" needs to be positioned correctly relative to the parent AND blender has to know that (ie, that Inverse thing).
[18:25:03] <spliff> if the node is positioned relative to the models origin (0,0,0) instead of the parents origin you'll get effects like the child being "flung" around 
[18:26:55] <spliff> when you apply a nodes transform you're actually telling blender to edit the mesh
[18:27:25] <spliff> which is perfect for the scale property by probably bad if the child is rotated
[18:27:50] <spliff> because then the mesh is rotated inside its box
[18:29:07] <spliff> wether that is what you want probably depends on the animation (like where the rotate happens)
[18:29:28] <[1uP]CarRepairer> when you say mesh is that like a spring piece?
[18:29:39] <spliff> No
[18:29:50] <spliff> the "node" is a spring piece
[18:30:01] <spliff> node = object
[18:30:20] <spliff> the mesh a visual thing you see inside the node
[18:30:37] <spliff> a node doesn't even need a mesh I think
[18:31:20] <spliff> when you click an object in blender a box appears around the mesh. that box is the node/piece
[18:31:45] <spliff> when that box is moved/rotated the mesh goes with it
[18:32:30] <spliff> blender calls nodes "objects", the terms are equivalent
[18:33:03] <[1uP]CarRepairer> lets say i select the rotor in blender. i put the  ursor im the center and set the rotor's origin to be at that point
[18:33:49] <[1uP]CarRepairer> now in spring anim i can tell that rotor to startspin
[18:34:06] <[1uP]CarRepairer> is it not guaranteed it will spin correctly?
[18:35:08] <spliff> depends what direction you want it to spin in but yes it should rotate around its center as long as the origin is positioned at 0,0,0
[18:35:35] <spliff> where 0,0,0 is relative to a parent
[18:36:13] <[1uP]CarRepairer> wait
[18:36:24] <spliff> things get funky when it isn't at 0,0,0 and you've moved it off the axis
[18:36:35] <[1uP]CarRepairer> i said that i put the rotor's origin at the rotor's center
[18:37:02] <spliff> that's the default yes
[18:37:24] <[1uP]CarRepairer> lets try a different example
[18:37:47] <[1uP]CarRepairer> i have a dude. i select his head
[18:37:58] <[1uP]CarRepairer> i set his origin at his neck
[18:38:18] <[1uP]CarRepairer> will it animate correctly?
[18:38:38] <spliff> if you want to rotate around his neck it should
[18:39:02] <spliff> it might rotate him around his face though
[18:39:15] <[1uP]CarRepairer> then whats the issue about nodes and meshes
[18:39:15] <spliff> depends on the rotation axis
[18:39:35] <[1uP]CarRepairer> why might it rotate around face
[18:39:53] <spliff> the issue is making sure blender and spring agree on where the origin actually is
[18:40:22] <spliff> because X,Y,andZ are all posible rotations
[18:40:47] <[1uP]CarRepairer> so it may not work 100% of the time
[18:41:10] <spliff> so if his face is pointing at X and you rotate around X his feet will leave the ground and he'll spin around his head
[18:41:23] <[1uP]CarRepairer> i might set origin at neck but spring could disagree?
[18:41:42] <spliff> that's not what i'm saying. I'm saying "work" is a matter of opinion/context/intention etc
[18:41:57] <[1uP]CarRepairer> im not rotating feet right now, just head
[18:42:30] <[1uP]CarRepairer> like a nodding motion, and later a head turn
[18:43:14] <spliff> in that case the head might might spin off the body and swing under the feet if blenders global coords are passed to spring as relative coords
[18:43:53] <spliff> if you moved the head from the models origin
[18:44:17] <[1uP]CarRepairer> so if that happened how do i fix it
[18:45:32] <spliff> by parenting the head to a neck object that's a child of the body and making sure all positions are relative to parents
[18:45:57] <spliff> you'd movce the neck piece up from the bodys origin
[18:46:24] <spliff> and move the head origin down to the base of itself
[18:46:45] <[LCC]jK> 1. uniform scaling are okay 2. POT textures are still the way to go when you want to support old hw (all NV support NPOTs, but ATi just support it from their HD3xxx series and duno about intel) 3. nice windmill
[18:46:56] <spliff> it's a bit hard to explain, images would probably help
[18:47:21] <[LCC]jK> there are myths that POTs are faster, I don't think so
[18:47:37] <spliff> how is uniform scaling ok? i thought we don't use it
[18:47:47] <[1uP]CarRepairer> my brain hurts. is it possible that if i do the shift ctrl p thing, then reposition pieces, then everything should just work
[18:47:47] <[LCC]jK> I explained it
[18:47:59] <[LCC]jK> it has to do with LA & matrices
[18:48:20] <spliff> do you mean uniform scaling would work in spring now, or it could work in future?
[18:48:35] <spliff> as in, does the code respect scale?
[18:48:53] <[LCC]jK> it wouldn't break normals
[18:49:27] <spliff> i know, but afaik any node/piece scale value is currently ignored
[18:49:56] <[LCC]jK> yeah, but it could be added
[18:50:21] <spliff> ok, just wanted to be clear there
[18:51:04] ** [LCC]jK left the channel( Quit: Exiting ).
[18:51:08] <spliff> because I'm planning to post this chat log as a temporary measure while I write a proper assimp tutorial
[18:51:13] ** [LCC]jK joined the channel.
[18:52:15] <[1uP]CarRepairer> i was hoping this would work like upspring
[18:52:38] <[1uP]CarRepairer> set up hierarchies, set each piece's origins, done
[18:52:40] <spliff> jK: how difficult would it be to rescale normals in a non-uniform way during import?
[18:55:32] ** [1uP]CarRepairer left the channel( Quit ).
[18:59:45] <[LCC]jK> <spliff> jK: how difficult would it be to rescale normals in a non-uniform way during import? > you couldn't use the 3x3 modelview matrix then, instead you would have to calc   N=transpose(inverse(ModelView))
[19:00:35] <spliff> jK: is that slow or just complicated?
[19:00:52] <spliff> cos i was kind of hoping assimp could do it for us
[19:01:10] <spliff> but it can't
[19:01:31] <spliff> my main concern is what happens to animations
[19:02:08] <[LCC]jK> not backend complicated (except the case where none inverse exists), neither slow on the CPU (GPU is different)