Hi there.
Things are quite calm here, so I ask how MtI improvements are going.
What can we expect next?
In all things that I can think off there is one thing that seems not to be very complicated and that should be implemented in MtI, Bake of constrains.
CTZn, you could try to implement it if you are not doing other things for MtI. Take your time and do the thing at your one pace.
By the way, the MtI code could be used to make a mll plugin without making everything from scratch?
[REQ] Bake constrains
Re: [REQ] Bake constrains
It would only make sense to use the UI code, and even then with an integrated c++ plugin the current MtI UI would be irrelevant. So: no. Being based on the Maya API rather than scripted ways, the code from an integrated plugin would be totally different (beyond the respective languages differences).
Constrains. May do, should be easy indeed; I'm just not easy with coordinates matrices.
Use this thread to bump your request any time, and the Indigo Requests forum otherwise, thanks ior.
Constrains. May do, should be easy indeed; I'm just not easy with coordinates matrices.
Use this thread to bump your request any time, and the Indigo Requests forum otherwise, thanks ior.
obsolete asset
Re: [REQ] Bake constrains
I have revised my opinion and will not add constrains support. At this point that would mean building one mess atop another, or rewriting the whole mesh pipeline, and I don't see either happening.
I was lazy at implementing IGQ support so I have to lauch files manually with the working copy. I will post an update at some point (adding fluids notably).
I was lazy at implementing IGQ support so I have to lauch files manually with the working copy. I will post an update at some point (adding fluids notably).
obsolete asset
Re: [REQ] Bake constrains
Fluids! That will be nice.
How are you translating voxels to mesh? Can it be used to make 3D data with transition gradient info between 0 and 1 inside mesh?
How are you translating voxels to mesh? Can it be used to make 3D data with transition gradient info between 0 and 1 inside mesh?
Re: [REQ] Bake constrains
I didnt realize that you had a thread WIPs, CTZn.
Checked that now and there is lots of interesting stuff there. And now I know that the voxels are exported as spheres and you speak of octrees there, so, keep up with the good work.
I liked also the indigo editor ISL additions.
Ill see more from the beginning of the thread.
Checked that now and there is lots of interesting stuff there. And now I know that the voxels are exported as spheres and you speak of octrees there, so, keep up with the good work.
I liked also the indigo editor ISL additions.
Ill see more from the beginning of the thread.
Re: [REQ] Bake constrains
Working on MtI took the little pretention to wips I had, I'm veleitary anyway but thanks. From there I don't want to go into elaborate stuff anymore such as octrees (did I ?). I'm not sure of the current status but particles instances may be to support (if not supporting) custom transform attributes.
Constrains rely on mechanisms I had great troubles to harness and wich I'm still very uneasy with. This resulted in the main weakness of MtI as you know it, transforms handling.
Constrains rely on mechanisms I had great troubles to harness and wich I'm still very uneasy with. This resulted in the main weakness of MtI as you know it, transforms handling.
obsolete asset
Re: [REQ] Bake constrains
I do not think you need octrees, I should know what octrees are before speaking about it.CTZn wrote:lycium, octrees you said ? Hehe, why should I say no* !? Where the displaceable spheres already XD (woops) ?
edit: ah, that would rather be from point datasets (density/homogeneity to octree resolution) ?
* Because Maya does not manage octrees natively !
But in your point distribution you could associate density with a material, having an array of materials for density in witch each material is associated with a density value instead of bigger spheres when density is higher. the option to use spheres is good and it should be there as well.
In that case each material should have higher precedence as density increases or decreases.
The density could determine what parameter the user decide density to act on, like putting density controlling color, or IOR, or scatter, etc.
What do you think?
EDIT:seen the video again and the spheres seem to get larger with speed not density.
Re: [REQ] Bake constrains
I considered an array for temperatures (light emission) and will possibly do that, but right now I'm interested in the Indigo scatter.
The attribute read for spheres radius is density indeed, incidently the denser zones may be the hotter, hence the most veloce.
If I understood correctly, octrees are to voxels what subdivisions surfaces are to meshes; there can be fewer, larger ones where there is little discrepancies in features size (hierarchical detail). Several voxels with an homogeneous density could be merged into one big sphere. That's just one property from octrees I'm guessing. But doing this recursive lookup in MEL would slow down things big time, that's not happening sorry Exporting all (non empty) voxels is faster. With Mel there's little chance to produce this kind of data faster that the disk can write it down I believe.
One could use the density ramp to hollow the volume out, then fill it with a lower res copy. Actually, that might be one neat application for the soup upres node, with the upres'ed fluid defining lower densities for instance (exterior details more).
The attribute read for spheres radius is density indeed, incidently the denser zones may be the hotter, hence the most veloce.
If I understood correctly, octrees are to voxels what subdivisions surfaces are to meshes; there can be fewer, larger ones where there is little discrepancies in features size (hierarchical detail). Several voxels with an homogeneous density could be merged into one big sphere. That's just one property from octrees I'm guessing. But doing this recursive lookup in MEL would slow down things big time, that's not happening sorry Exporting all (non empty) voxels is faster. With Mel there's little chance to produce this kind of data faster that the disk can write it down I believe.
One could use the density ramp to hollow the volume out, then fill it with a lower res copy. Actually, that might be one neat application for the soup upres node, with the upres'ed fluid defining lower densities for instance (exterior details more).
obsolete asset
Who is online
Users browsing this forum: No registered users and 1 guest