PDA

View Full Version : Mesh Part Displacement Loop, nearly...



raw-m
12-01-2018, 06:52 AM
Hi all, having trouble creating an infinite displacement loop I'm hoping someone can help with?

Basically, 3 objects in the same layer and using Mesh Part to simply displace each object 3m when they touch the base. I had thought that this would work automatically but it looks like this setup is only seeing the mesh centre locally and not in world co-ordinates(?) - so it does what I need but only the first time around.

Anyone know how to modify this so it's constantly looping?

Scene attached if it helps visualise :D

MonroePoteet
12-01-2018, 03:34 PM
I think the basic problem with the setup you posted is that once each Part is displaced by 3.0 in Y, that's where it'll stay. The next time it passes the Null (named "follow" in your example) position, it will be "re-displaced" to 3.0 again, staying in the same relative position to the parent object as the parent moves.

I don't know if it'll work for what you want to accomplish, but you could calculate the World Position of the Part relative to the control Null, then calculate how many times it's been moved by dividing the calculated Y position by the overall size of the parent item (3.0 in this case).

A sample scene is attached, with the setup being:

143473

In the sample scene, the Nodal Displacement to move the overall, multi-part object was removed and an Envelope was used to move the overall, multi-part object negatively in Y. This allows the current position of the parent object to be available in the node network. I also moved the control Null (follow) to demonstrate the behavior if the Null moves rather than (or in addition to) the overall object.

Hope it helps!
mTp

RebelHill
12-02-2018, 10:13 AM
Yeah... I dont *think* this can work.

The node editor gets (at the 'input state') the geo as it is. Once it's gone through the pass once, it would have to see the new positions of everything, their displacement result, which it can't do, because the displacement sin't applied until the output node. I can see how one might think it should work, since at each new frame it should see the mesh as it is at that frame... but I'm pretty sure it won't.

The only thing I can think of is to copy and stack the node displacement is the disp stack. Ofc, you'd probably have to add in extra nodes to each, so they can only apply after a certain frame, or ull get double transforms, etc.

I'll see if I can think of or discover anything else otherwise.

raw-m
12-02-2018, 10:23 AM
Many thanks for all your times in answering and the breakdown, RH.

I’m aiming for something along these lines, which (I thought) i was nearly there with. I think I could probably loop in post if I’m careful with my timings!
https://www.instagram.com/p/Bq2y3OjB23a/?utm_source=ig_share_sheet&igshid=1rn5jcpdhgdn1

RebelHill
12-02-2018, 10:49 AM
God... u know what that makes me think...

Portal... LW needs a "Portal" item, where you can move geo into one gate and have it emerge, pacman style, from another.

raw-m
12-02-2018, 11:48 AM
That’s such a great name for it, too! I’m going to put in an FR :D

Stumbled across this too, from 13.35 (some c4d deformer, or other)
https://youtu.be/Zri9U3pGO-I

jwiede
12-02-2018, 01:30 PM
God... u know what that makes me think...

Portal... LW needs a "Portal" item, where you can move geo into one gate and have it emerge, pacman style, from another.

Ayup. Though "devil's in the details" as well, for example:

1. Need to resolve whether geo moves all at once when object/part center crosses the "threshold" or bit-by-bit as the geo bits touch/cross the "threshold"?
1A. If the latter in #1, then what about geo that doesn't touch?

2. It should probably be able to "trigger" (com ring?) other events when the "transfer" event(s) occur, or maybe as start/stop events if doing bit-by-bit and/or delay.

3. Do objects/entities retain momentum across portal transfer?
3A. Can portal transfer impute/change momentum of objects/entities transferred?

4. Needs a control for object/entity inclusion/exclusion list.

5. A control for enveloped delay between "entry" and "exit" also seems useful (perhaps texturable if bit-by-bit?).

The more I think about it, it's kind of like what you really want is a way to position "thresholds", where entry events trigger a script of some sort, and potentially with associated "exit threshold" defined. It's not just a single operation, it's kind of a toolkit, which would also better lend itself to nodal configuration/setup (though you'd want some specialized nodes to support operations like "run cmd" | "run script" | "send pfx collision-event" passing entity as param if possible, "wait/sleep", and so forth.

Looking at it another way, there's a lot of similarity between described and the basic primitives in a rules-based particles/group-behavior engine.

Hmm... :stumped: