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 ... 794
1
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.

2
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.

3
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.

4
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?

5
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?

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

Quote
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?

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

8
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: http://www.jpct.net/wiki/index.php?title=Loading_models

9
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.

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

11
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.

12
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?

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

14
Support / Re: Camera rotation.
« on: May 14, 2018, 07:53:46 am »
Code: [Select]
camera.getBack().setIdentity();

might be a little more efficient.

15
Support / Re: Float Positioning Blit Images
« on: May 03, 2018, 11:26:25 am »
No, it's not possible but you could use an Overlay instead.

Pages: [1] 2 3 ... 794