check out the "rescale" message (it defaults to "on").

I tried with [rescale 0 ( and [rescale 1 ( and have the same output.

Antonio

On 1 April 2017 at 20:20, zmoelnig@iem.at wrote:

On 03/31/2017 11:40 PM, Antonio Roberts wrote:

...

I'm using [multimodel] to load an animation of obj files made Blender. As I play/scrub through the files I noticed that the begin to shift around without me having to use translation or rotation. Below is a video made to illustrate the problem. The actual objects I'm using differ.

https://youtu.be/jPzHYZTSwYo

When it comes to setting the scale it appears as though it is using the centre point as origin and then expanding to fit the area of the objects. Is there any way to stop this? In other models I've made it seems as though a corner is being set to origin point.

Is this something I can address with Pure Data or do I have to do it in Blender?

check out the "rescale" message (it defaults to "on").

gfdamrs IOhannes

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

...

I tried with [rescale 0 ( and [rescale 1 ( and have the same output.

you *must* send the [rescale 0( message *before* loading the models.

I definitely did this. If you check the order of messages in the video you can see that it is sent first. (I did another test with [rescale 1 (

On 2 April 2017 at 19:23, IOhannes m zmölnig zmoelnig@iem.at wrote:

On 04/02/2017 05:16 PM, Antonio Roberts wrote:

...

...

check out the "rescale" message (it defaults to "on").

I tried with [rescale 0 ( and [rescale 1 ( and have the same output.

you *must* send the [rescale 0( message *before* loading the models.

mgadsr IOhannes

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

I've fixed this problem by adding into the obj file some vertex to make a cube around each object, same size larger than every objects opened by multimodel. The cube can be invisible if it's in another group, or by using a vertex shader.

It would be great indeed if multimodel wouldn't normalize values from the obj file

Le 02/04/2017 à 21:17, IOhannes m zmölnig a écrit :

On 04/02/2017 09:10 PM, Antonio Roberts wrote:

...

I definitely did this. If you check the order of messages in the video you can see that it is sent first. (I did another test with [rescale 1 (

i have to admit that i don't watch youtube videos for bug reports. could you provide a test-patch that exhibits the problem.

it also might help to know which platform and which version of Gem you are using.

gfmards IOhannes

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

On 04/05/2017 07:32 PM, Antonio Roberts wrote:

Attached is a zip with the pd patch, models and blend file.

thanks. for me the example works nicely, as soon as I change the message to [rescale 0( (after all: you *don't* want to rescale). i've tested with both Gem-0.93.3 and the latest git (both the OBJ and ASSIMP3 backends)

with rescale 0:

• the cube stays in the center of the image
• the octaeder ("sphere") moves back and forth along the x-axis

with rescale 1:

• both objects become smaller and larger

this is quite expected: rescale 1 scales/shifts the model so that its bounding box fits nicely into a unit bounding box (aka [cube 1]). since the various models have a bounding box with an oscillating X-size (because the octaeder moves along that axis), rescaling will (well,) rescale the the entire model in an oscillating way.

i think the default [rescale 1( is nice for quickly getting a model to display in sane coordinates. unfortunately any serious work with models requires a [rescale 0(. for backwards compat reasons, it is unlikely that the default will change.