ZBrushCentral

z-spheres flip axes problem - its not zspheres but mm problem

first, let me say, that i really love zbrush. it is the most fun program i ever had, and it is the most stable one. in all the 5 month i have it now, it never crashed, and it always does what i want, except… (oh, i really hate to complain…)

i got a problem, that is, i re-experienced a problem i earlier had sometimes. now it annoys me, please help.

what i did.

man.ztl was modeled from zspheres, in preview window, he looks to front (as in 1). quit zbrush, re-open zbrush :

  1. man.ztl placed, markered, 2 spheres placed and marked.

  2. with multimarker tool draw (all looks fine at this moment), then rotate so that nose points to right. press twice “t” to leave modeling mode. press reposition. clear canvas, then draw. the result is 2. the eyes are correct, the head is upside down.

  3. export man.ztl as obj with all settings as default. import man.obj and draw on canvas. this is 3. it is flipped in x-achses

please help - this bugs me often, and makes it impossible to make polymeshes where one of the tools is zspere model. i also remember that mentat asked a similar problem (or may be same ?) once, but i think it was not completely resolved… i experienced the same kind of problem only with zspere models, yesterday for example i downloaded auricks quad-view modeling help-script, and there, even in the “show me” the front model was upside down, and also when i tried out, zsphere models were upside down.

i think, may be, the zsperes have for their “internal calculations”, one of the axes flipped… ? this could possibly explain also the texturing issue when im- ex-porting textures, there was a long discussion lately, where pixolator helped with some scripts…

did you set axes so it looks like image 1 in tool>modifiers window before exporting instead of correcting position with cursor?

it was not neccessary in my case, as i always model from the beginning with the zshperes, so that they look to correct direction in tools window, since i thought setting axes might the problem…

Ho Kokoro
When you export you can choose somme XYZ flips :slight_smile:
Ok It’s a tricky solution but before Pix examine your case I hope this help :slight_smile:
Pilou

thanks, frenchy pilou - but the main reason i brought this up is that this flipping problem makes it impossible for me to build poly meshes which contain a zshpere model. for the other issues i do help myself with flipping etc… i wonder whether there are other people around having that particular problem, or if its just me ?

I have been doing testing and have not encountered this problem with either Adaptive or Unified skins. The MM tool has consistently been drawing my models with the precise orientation of the model on the canvas at the time that the marker was placed.

Could you send me the unskinned model along with a recorded session where you skin the model and then attempt to create a MultipleMarker polymesh with it? I might be able to figure out where things are going wrong.

My email is [email protected]

thank you aurick. i try to do so. i mean i never have recorded something, but should not be too difficult. i will do so tomorow. thanks a lot.

edit : oh, by the way, the mistake only occurs after rotating the mm tool and reposition it… not when i draw it straight as i had marked it first

i finally tracked down the problem, i think. its not a zsphere problem as i thought, but a multimarker-problem. it occurs only when i rotate a multimarker object exactely 90 degree to the right, and then reposition the multimarker. the skripts below show this.

the first skript contains a mm rotation by about 45 degree, that works fine after reposition, and it contains a new mm now rotated exactely 90 degree, which produces the flipping after reposition, the result is this :

m1.txt

the second builds a mm object from skulpted primitives, no zsphere object contained, then rotated 90 degree and reposition, and voila the flipping occurs :

m2.txt

this seems to indicate that mm work internally with quaternions to calculate the rotations (which give the smoothed rotations when animating, as far as i know), since these can rotate correctly only degrees 0 - 179. and rotation by 90 degree to right is also rotation by 270 degree depending on the orientation of the axes, so such rotation needs to be composed of at least 2… i might be completely wrong with that. but i think now, its not me being stupid with mm´s, but there could possibly be a very tiny bug in zbrush… hope you do not mind this suggestion.

It’s my understanding that quaternion rotation is superior and does not have this problem. It is Euler rotation that has the problem of flipping by PI radians (180 degrees) in one axis at certain times. Lightwave uses Euler rotation, and it and some other 3D applications are susceptible to ‘gymbol lock’ because as the rotation of an object approaches the 180 degree limits, calculation results become less precise and sudden flipping on an axis can occur. This is why Lightwave has been less than desirable for character animation in the past. The gymbol lock problem, due to the use of Euler rotation, makes the positioning of arms and legs for each keyframe more difficult. However, I could be wrong about ZBrush, of course, since I don’t have the ZBrush source code.

You can see this in ZBrush if you place an object and go into TRANSFORM:ROTATE mode, and attempt to free rotate with the mouse. As you rotate, look at the values in the sliders in TRANSFORM:INFO. Also, you can try this simple experiment: Place an object and make sure its rotation is 0,0,0. You can do this by going into TRANSFORM:ROTATE mode, and then setting all of the TRANSFORM:INFO sliders to 0. The object will have the same orientation as its representation in the TOOL:MODIFIERS:Preview window. In the TRANSFORM:INFO:Y Component slider, set the value to 89. The object will be rotated on screen 89 degrees to the right. All is fine. Now change the rotation to 91 degrees using the TRANSFORM:INFO:Y Component slider. Suddenly, the object is flipped 180 degrees on the object’s Z-axis as it passes the 90 degree orientation on the Y-axis. To get it oriented back, the Z-axis must be set to 180 degrees. To rotate an object to the right all the way around 360 degrees, maintaining it in the ‘upright’ position, then the Z-axis rotation will have to be set to 180 degrees when Y-axis rotation is equal to 90 to 180 degrees and -180 to -90 degrees, and when Y-axis rotation is between -90 to 0 to 90 degrees, Z-axis rotation must be set to 0 degrees.

Yuck. This makes programming ZScripts that rotate the object to a specific orientation a bit of a challenge, which I am currently attempting to do.

The only work-around I know for working with Multi-markers is to make a polymesh out of the MM object. Then it can be rotated to any orientation and used in a larger more complex MM object.

By the way, I don’t think of it as a Multi-marker problem. It is more of a rotation problem, affecting anything having to do with rotation, whether it is the rotation values stored in a Marker, or a zscript, or a user attempting to manually rotate an object into position using the TRANSFORM:INFO sliders.

thank you jaecephus for correcting me. i mixed the names of the rotation methods. anyway that what you describe was exactely what i meant.

i hope it is not a problem that i do rotations manually… :frowning: as i do not like to type values…