Moho Forum

Hi!
Here there is an example of what can be done.

http://www.darthfurby.com/genete/Other/3Dleg2.zip
(the zip files include all the needed scripts to make the file play)
http://www.darthfurby.com/genete/Other/3Dleg2.mov

It is like a longitudinal section of a leg (thigh, knee and calf)
Please watch carefully the anme file to realize that the thigh is 3D binded (*) to a bone called "c", the knee is 3D binded to a bone called c_87.pt and the calf is 3D binded to a bone called c_85.pt.
Notice also that c_87.pt is 3D binded to "c" and c_85.pt is also 3D binded to "c".
All the bones binded to "c" rotate by masterX and masterY bones.
All the bones binded to c_87.pt rotate by c_87.mX and c_87.mY
All the bones binded to c_85.pt rotate by c_85.mX and c_85.mY

c_87.pt and c_85.pt are very close but not the same point. It allow to have two independent mX and mY bones for each.

Also I have included a trick that is that rotation of c_87.mX is controlled by 0.5 times rotation of c_85.mX, to have the knee properly placed each time.
c_85.mY and c_87.mY are useless. (they wouldn't rotate unless the leg were broken )

Forgive me about the tutorial but I still making tests with the scripts. There are some situations were the auto 3D rig don't work properly. I have to fix it.

Please be patient.
Regards
-G

(*) Sorry for the free speech.

Genete,

Sorry for not being able to work on this project more than I have. The "real" 3D world keeps getting in the way! I have to pay the bills right?

Anyway I keep coming back to the same thought over and over...

Why use bones to move the individual points? I keep thinking there would be a way to do this directly to the actual vector points instead of adding in the bones.

Bones would be needed of course but only for the "parents", the bones that can be moved to adjust the shapes. The points locations themselves could be stored in the same array and the points moved "on the fly" by the script.

If you have already suggested this and I have completely forgotten please forgive me. Too many Dukes of Hazzard reruns in my head.

-vern

Errr,,, Now I am a little busy in other personal stuff (my sons are 15 days in vacations with me... mmm very busy really) so for the moment I only am reading the forum to not loose track on the posts. None further developments although I am very eager to take up again the researching.

Regarding to where store the x,y,z information It was something that I though also in the past but abandoned it.

Let me think about it out loud and see what can we conclude.

1) You want to eliminate Rx, Ry and pt bones.
2) It is not possible to eliminate the central bones of the limbs because its name is connected to the mX and mY bones that makes their individual rotation. It also represents the center of rotation so its position define the center of the model (or the limb).
3) The parent ship of the points of the limb (that previously was done by the parent ship of the pt bones to the central bone can be substituted by the value "parent bone" of each point. "A point belongs to the limb that its (central) bone parent belongs to" That's a good point (if you forgive the repetition ) for the future 3D rig
4) To store the x,y,z of every point we can use some kind of array similar to the current for TboneSets. It obligate to maintain the points of the side view available all the time. That's not a problem. Also to assure that it is always available it can be calculated in every embedded script call. Same than current design.

Conclusion. It is possible!!!! The amount of bones would be reduced drastically!!!

Let me state some rules (if you don't mind) over some ideas on the fly about this...

1) Draw a model (it could be front or side view or 3/4 or what ever) lets call it original model.
2) Based on that model draw (moving points) your front and side views in each separated layers. Lets call them front and side models.
3) Based on front and side models the user make a 3D rig of the original model. The names of the layers of the original, front and side models should be consistent (face, face.fr, face.sd for example) It would be needed for the script to select the original model layer to move it on the fly. That 3D rig would need masterX and masterY bones and every eventual mX and mY bones and its corresponding central bones of the limbs. In one model without any limb it only would be needed 3 bones. A central one and the masterX and masterY bones.
4) Once you have rigged our model you can animate it with the masterX, masterY and mX and mY bones (and fov and master TR bone for sure!)
5) ALSO ( and you now would understand why have tree layers) You can morph your model just moving the points locations of the side and front models!!! That was one of the reasons for what I discarded the no bone idea!!.

More features!
Now masterX and masterY can be deprecated! We need only mX and mY bones!. In this way it is possible to have more than one model in the same vector layer (bone layer)! It would be VERY interesting because the current design loose some interactivity with the 3D models. Imagine it! now you can have two models (3D characters) in the same layer and sometimes one is above the other and sometimes is behind!. All the work is only done by the sort shapes script!!!
BTW the short shapes script would work the same because finally the Z value is taken form the points and not matter if the z value is attached to a bone or to an array.

Ouch! I have no time now to work on this!!! Also I've planned to make a trip the last week of July!!
If you feel brave to write the script please don't hesitate to do it. Although I would be very happy if I could do something.
In August 1st I'll be 100% on this stuff...
But before start witting the behavior of the model should be better defined. My recommendation is this:
First create the model by hand and modify the 3Dgrid script to make the magic.
When it works perfectly (included limbs) then modify the auto 3D rig scripts and the sort shapes script. I predict that the auto 3D rig script would be useless finally. We would use the standard bind points and re-parent bone tools... Only the shape sort would be necessary.

This is exciting!!!
-G

you'd have got away with it too if it hadn't been for those pesky kids!!!

i know the feeling

This is from another thread, viewtopic.php?t=8942, proposing an alternate 3D vector system for the next version of Anime Studio. I thought I'd post my reply here as it's more relevant to this thread than that one.

Genete wrote:Regarding to the mention of heyvern about the lighting of the model I have some ideas about it. They are very basic because would require user interaction for every shape during the design of the model. Let's say that I have not found a way to automatically know what's the outer side of a shape (the one that's lighted or darked).

Couldn't you make your script guess the orientation of the normal vector of each face at creation, ie always pointing out of the screen. You could then have a tool to flip the normals for selected faces later on. That doesn't seem too clunky to me and I believe is how most 3D programs deal with it. Sure there are automatic normal vector generation algorithms out there, but I think it would be overkill for the low face counts you would be dealing with.

You could then have a tool to flip the normals for selected faces later on

That's what I mean by "user interaction". The script should select a normal orientation based in the forming points of the shape, but you know only by the x,y,z values of the holding points is impossible to know if a normal is outside or inside of the model.

I plan that the shape holds a 3D vector that represents the outer normal of the shape. As well as in the current state of development a "3D shape" is not flat, the normal is an average normal. Once the shapes are defined and the light is "on" the user should decide (where he notice that the script has failed in its outer normal calculation) to change the sign of the normal, turning it lighter if it is dark or darker if it is light.

The "normal" vector of the "3D shape" will be calculated as the average cross dot of pairs of vectors laying in the "curved" surface of the shape theaverage must be intelligent adding only to one predefined direction (sign).

Later I'll do a loop for every shape, look its normal and compare (in angle) with the light position, then I'll dark or light the shape's color. It is not so difficult but requires time that I haven't so much now.
The loop would be done in the same script than the Z shape sort.
-G

Cool, that sounds like it should work pretty well. I like that you intend to store the normal vector and let it transform with the shape instead of calculating it on the fly. Should be faster.

I wouldn't sweat the shape orientation issue at all. It's just a fact of life with all 3D programs. I've certainly done my fair share of normal flipping inside 3DS Max.

I know you won't stop even after you've added lighting to the script. I'll be following this project closely to see how it develops.

Genete,

For the "point only" 3D concept... it is possible to "rotate" a group of points based on a specific axis. It might be possible to store the rotation point for a a group of points. It would always "rotate" based on that point. If for instance a set of points are the "forearm", they would have a rotation axis at the "elbow" which would always be the same spot "relatively".

One of the things I need to look into is if this will create point motion keys. That was what is nice about the bones solution... no keys. I am pretty sure there should be a way to move points without keying them like the way bones can move and rotate from a script with out putting in a key frame.

-vern

Rudiger wrote:Cool, that sounds like it should work pretty well. I like that you intend to store the normal vector and let it transform with the shape instead of calculating it on the fly. Should be faster.

I wouldn't sweat the shape orientation issue at all. It's just a fact of life with all 3D programs. I've certainly done my fair share of normal flipping inside 3DS Max.

I know you won't stop even after you've added lighting to the script. I'll be following this project closely to see how it develops.

Really I plan to calculate the normal on the fly... It is due that the rotation of the points and thereby the rotation of the normal is not a classic matrix rotation. It is a fake 3D rotation. I suppose that a complete 3 axis rotation can be done mathematically but I'm sure that the user would reject it. Now is complicated so far that most of users scares about angles, rotations, and so on... I want to let it as it is; two rotation axis and one of them depends on the other.

------------

heyvern wrote:Genete,

For the "point only" 3D concept... it is possible to "rotate" a group of points based on a specific axis. It might be possible to store the rotation point for a a group of points. It would always "rotate" based on that point. If for instance a set of points are the "forearm", they would have a rotation axis at the "elbow" which would always be the same spot "relatively".

One of the things I need to look into is if this will create point motion keys. That was what is nice about the bones solution... no keys. I am pretty sure there should be a way to move points without keying them like the way bones can move and rotate from a script with out putting in a key frame.

-vern

Regarding to the rotation points of the limbs I have some ideas in mind let me explain to you and let me know:
a) There are three vector layers (model, model.FR, and model.SD) Its names must be consistent.
b) I will not distinguish if the script is calculating the rotation of a limb or not. The treatment should be always the same:
- There are three loops: one that store the bone skeleton a second one that rotate the skeleton and a third one that moves and store the point "skeleton".
- The bones skeleton works similar to the previous version: bones are parented and its x/y projected position is relative to it parent bone. So the user should define a kind of skeleton done with bones that rotate one around the others like if they were the joint center of the skeleton (the wrist rotation center rotates around the elbow center and it also rotates around the shoulder center)
- Once defined the rotation centers (you can define the skeleton partially) the user select a group of points and bind (bind in terms of AS bind, I mean real 2D bind of points to a bone using the bind points tool) to the central bone. Do it for all the points for each corresponding center of rotation bone. This binding must be done in the model.FR layer.
c) The first loop would look to the bones and store its values into an array. It would store:
bonename.Rx (the one whom the points are binded)
bonename.Ry (is corresponding bone to the side view)
bonename.mX (the bone that perform a local X rotation to the bonename submodel) It would store the angle value (global angle of the bone)
bonename.mY (same but for Y rotation)
d) the second loop would move the central bones to its corresponding position depending on the rotation of its parent mX and mY bones. Same than the original script
e) The third loop would search to all the points in model.FR, ask if it is parented and also ask if the parent exists in the previously calculated array. The bones should be stored by its ID that is the most direct way to access to them and also is the returning value of the fParent value of the point object.
If it exists then the point belongs to the local mesh. Using the angles of the mX and mY bones and its relative position in the model.FR and model.SD layers to its corresponding central bones (remember that those layers have same points and same points ID) calculate the projected x, y and z values. MOVE the corresponding point of the model layer (the one what is going to be moved) to the calculated x and y position and STORE on the point the Z value (same solution than for the pt bones). The movement of the points in the model is relative to the parent bones that are yet moved.

For shape order It would be similar. For each shape go through all the holding points, look to its Z value (already store on it ). Ask if the point has a parent and test if it is a .Rx bone then calculate recursively its Z value passing by its ancestors bones until it reach a root bone. Once the Z of the shape is calculated just sort them.

Phew!
It could have some concept mistakes but everything seems consistent.

Regarding to the ability of move points without create a keyframe that's the most important issue. It it does not work The script is a little useless. I don't want a bunch of point keyframes in the timeline. It should be an option for those who want to store the keyframes and later unload the script and have the point motion already done (ready to render).

Please check it out Vern! can points be moved without store a keyframe? I'm afraid it wouldn't be possible ...

Please comment.
-G

Vern,
I've tested the fPos variable of the point and have very strange results.
See this file:
http://www.darthfurby.com/genete/Scripting/test3.zip

There are two files:
test3.anme and test3.lua (the embedded script)
It have different render if the selected layer is the bone layer or the vector layer

Please can you do an example with fPos or SetPos to know if we can mode points properly by the timeline?

-G

BTW it does not render properly to swf (the result is an static image). It render properly when export to image sequence and don't have influence if the selected layer is the bone layer or the vector layer.
But if you make a single render (CTRL+R) the render is different depending on what is selected... Weird, weird, weird...

Yikes!

That is... weird!

It could be we should stick with what works (bones for points). If it ain't broke don't fix it.

I have tried in the past to move points around with scripts but I never had much luck unless I put in a key. I will admit that I didn't try very hard and just assumed it could be done if I put in more effort.

I will look into this and see if there is something else going on with the script. That behavior is very very odd and the script is pretty simple.

My first thought is that there is something going on with updating the UI or the view. When I have the vector layer selected I get a "double image"; two "versions" of the circle in two places, one is the fill and one is the outline or construction curves... very strange.

We may want to put this idea off for later experimenting. I would hate to get to involved trying to fix an odd "bug" in the AS interface when the bone solution works so perfectly.

-vern

I would hate to get to involved trying to fix an odd "bug" in the AS interface when the bone solution works so perfectly.

Me too
-G

Continuing with the trials let me show you a 3D rigged sphere with the minimum amount of points that make is more or less completely rounded.
I have created a simple eyeball. Also I have left the outlines to the back side of the eye to let you know how is it built.
Please, notice that, at frame 0, the back side of the ball is placed above the front side of the ball of the FRONT view. It makes easier to make the links between points. It is later placed at is correct position by the corresponding bones at the side view. The points (and the bones) at the side view are correctly placed so the front view moves to it must be. Remember that the Rx bones only give the X information so its value is irrelevant. The Y and Z values are given by the side view points (bones).
I have solved some bugs of the auto 3D rig script. Please be patient. I'll make a tutorial with this 3D ball to show you how works the scripts.

http://www.darthfurby.com/genete/Other/eyeball.zip
http://www.darthfurby.com/genete/Other/eyeball.mov
Please play with the file and let us know if the embedded script work properly.
-G

This is another trial.
A 3D flower.

http://www.darthfurby.com/genete/Other/3Dflower.zip
http://www.darthfurby.com/genete/Other/3Dflower2.mov

Middle of august there will be a tutorial.
-G

Excellent, Genete!