thank you for starting implementing ODE - this is a great new tool !
I am trying to understand how it works in VVVV - are you planning / is it possible to combine the nodes for EX9.Geometriy and ODE in ONE node in the future ? This would clear patches up a lot I think.
Here two first questions:
Is it possible to adjust the “damping” of the movement of an object that moves on a flat surface without being influenced by gravity ? (is it clear what I mean ?)
Is it possible to adjust the amount of absorbance of movement after a collision for the ODE-objects ?
I think I have to study http://ode.org to understand the pins of the the WORLD(ODE) - or is there an explanation of the ODE nodes somewhere on this great new (but still a little confusing) VVVV-site ?
i just work on that … (combinig the geo and ODE primitives in modules)
the output will be a mesh and the specific transformation (matrix).
i will do for every primitive a static and a dynamic one.
did you think it is ok to make all input pins in vector format (spread of 3) ?
this question is important, in case of spreading the objects. connecting a simple spread to a vector input pin could cause confusion.
if i do a pin for every value (with vector join inside the module), the object gets very large, because i want to do for every transformation (translate, rotate, scale), an absolute and a relative input for building transform groups (of different objects).
whats your opinion to that ?
and:
how could i rotate a whole spread of ODE objects (not the objects itselfs) ?
ok, have it …
is there a possibility to transform a vector and get the (transformed) coordinates as values ?
thank You for these very helpful moduls.
Working with them I found out, that the Scale-Inputs of TransformODE are not spreadable.
Spreading works on the ODE-side but not for the displayed EX9.Geometry.
All the EX9.Geometries are scaled according to the first slice only, the other slices do not have any effect at all.
(see attached file)
The reason for this is, that the EX9.Geometries are not spreadable by spreading their input-dimensions.
The solution should be inserting some standard vvvvtransformations for scaling instead of directly sizing the EX9.Geometries
… I played around with this a bit but with no final solution (perhaps ages ago in school I should have listened more carefully in math when it came to Vectorrechnung !?)
I am sure you will find a way for this pretty fast.
