Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - EgonOlsen

Pages: 1 2 3 [4] 5 6 ... 797
Support / Re: Asymmetrical Scaling
« on: June 26, 2018, 09:04:23 am »
Looking at your code snippet again, I noticed that you set the glow's rotation matrix to the one of the object. I'm not sure if that's a good idea, because it sets the exact some instance. I might be better to make one the child of the other or do a cloneMatrix() on that rotation matrix before setting it. Maybe that helps.

Support / Re: Asymmetrical Scaling
« on: June 25, 2018, 08:38:12 am »
Have you checked which vealue you are actually getting from getTransformedcenter() before and after doing the additional translation. Something has to be there.

Support / Re: Asymmetrical Scaling
« on: June 24, 2018, 04:52:18 pm »
Maybe because the transformation as a whole is different (some additional rotation involved)? Try to offset the glow by a scaled version of the results from get?Axis() instead.

Support / Re: Asymmetrical Scaling
« on: June 22, 2018, 08:27:26 am »
Yes, you have to call build and yes, getTransformedCenter() should apply all parent transformations.

Support / Re: Asymmetrical Scaling
« on: June 21, 2018, 10:04:01 pm »
Must be something else then. The controller works in object space. I don't see how this code snippet alone can cause wrong scaling unless the object is somehow rotated around Z and your Z-scaling should actually be Y.

Support / Re: Asymmetrical Scaling
« on: June 21, 2018, 09:07:26 am »
The vertex controller works in object space, not in world space. What exactly is the problem?

I think that I don't understand your actual problem. The idea is: You create a new sub sequence, add all the keyframes, continue with the next one. If you animate a sequence, it's limited to that sequence's animations unless you animate 0, which includes all keyframes. What's the actual issue with that?

IIRC, it's by design. The docs say:

The sub-sequence will be numbered starting from 1. 0 is a special case as is represents the animation as a whole.

Isn't that what you are experiencing?

That's just some viewer application that displays an existing texture. I haven't done anything to it in terms of merging.

It doesn't work that way, because you are setting different texture on a merged object. How should it supposed to know where to put which? There's a two approaches to solve this:

  • assign the corresponding texture to the object before merging them all into one
  • let the auto-assignment do it's magic. Looking at your code, it seems like that should work already. Have you tried to remove your texture assigment code and see if works then?

More information on the auto-assigment:

Support / Re: Merging OBJ Frames
« on: June 04, 2018, 07:40:52 am »
Then something isn't identical between the meshes no matter what. If the vertex count would match, they would at least make it all into the animation. However, even then, the usage of these vertices in the triangles could be different as well, which is something that a keyframe animation can't deal with. The assigments of vertices to triangles have to stay the same in all files.

Support / Re: Merging OBJ Frames
« on: June 02, 2018, 09:22:36 pm »
Can you print out the actual values that you are comparing?

Support / Re: Merging OBJ Frames
« on: June 02, 2018, 09:58:08 am »
No, they aren't. RL_Face002 for example differs from frame to frame by +-1 vertex in that log file.

Support / Re: Merging OBJ Frames
« on: May 31, 2018, 02:42:55 pm »
In that case, the mesh sizes are different in the file. Can you check the log output while loading them for any differences?

Support / Re: Merging OBJ Frames
« on: May 30, 2018, 12:51:09 pm »

Pages: 1 2 3 [4] 5 6 ... 797