dear all,
i asked this a couple of days ago in the chat and I guess I’m simply stuck. I also learned to ask for help before going crazy, so I created a short video that explains my thoughts :-).
Basically I’m trying to implement the particle-example with the model-runtime design pattern that Natan shows us here.
The main problem is that I get either my StartPosition from the Model to the Runtime or that I’m able to change properties like speed or direction. I want it both! I want to think of the StartPosition as an Offset that’s added once to the position / or sets the position once in the create-operation.
Thanks for your reply, bjoern! That would also be the way to implement a reset-pin / reset-operation, I guess. Like I would have a ‘init’ method in any other oop language.
It just feels like “OnOpen” is outdated since we have “Create”. (And reminder to myself: check again how the wanderer-node is doing it)
Of course this is a solution for the task and I might also overcomplicate it atm…
thanks again, bjoern!
Have a look at the Integrator, you could it do it like that but I think you’d have to connect the PartcileModel to two distinct inputs. Or just use the Integrator inside your runtime, but you said you didn’t want to.
The patch that I provided was intended to show the clear split between model and runtime, but not necessarily being the final implementation that you should use:
in your patch you have a particle instance (runtime) getting created by the patch itself, in the main loop, so you don’t really have control over the “creation” of the particle and the “synchronization” of the model. they simply happen in Create and Update of your patch. In a proper particles system you would be interested in emitting particles (creating them on demand) which means creating them from an existing model and synchronizing them to the model. in this context you are in control of what happens when and you can make sure that the new particle get created and the initial position set before the update of the particle.
find attached another approach in which you handle not the model but a reference of it.
here you are able to pass around an initial state of the model (and the runtime can extract info from it on create) and then update it during Update of your patch
cheers
Dear dottore,
thank you very much for your reply. Seems like I tried to over-reduce / simplify the idea. Your patch with the reference made it quite clear though, thank you for your time and help!
see you soon,
clockdiv