• mapofemergence
  • First taste
  • Email
  • Posts 7
  • Reputation 0
  • Member Since
  • Last Active
Email
  • Profile Picture
All Posts Topics Started Likes
write a particle cache node
Thank you Peter for the hints, and the reassurance above all :)

As you put it, it sounds fairly easy (at least to start with).
I'll try implement a sketchy python version and if that works will move to proper c++.

I'm still wondering about the performance issues (even with c++, if cache files are big), and asking myself whether I'll need to care for memory handling or not.
0 0
aim constraint math
thank you @pshipkov, that is useful indeed.

I guess this is not the ideal place to ask, but could you share how you achieved that in nuke?

cheers,
s
0 0
write a particle cache node
Hi everybody,
  recently I was considering how hard it would be to implement a cache reader.
Currently, I'm considering this just as an exercise, but I have in mind a few specific scenarios this might be used for.

I have a decent (but yet limited) understanding of the steps I might go through to implement this but I have a few doubts, about which I'd like to hear some experts' opinions.
I hope I won't ask any silly question.


1. Should the node be an emitter or can it be a simple MPxNode?
I'm wondering what's the correct approach for the node's core.
I was thinking of a very basic MPxNode; it would read the files and output particles (and their attributes) as data arrays, directly into the particle system node (similarly to what I was doing here).
Is there any drawback in not basing the node on a MPxEmitter?

2. Should I emit 1-frame-lifespan particles? Is this what maya's native cache nodes do?
This is the most basic solution I can think of; I was wondering if there's any better (and not-to-complicated).

3. Any hint about performance optimization?
I would like to consider performances, at least to avoid pointlessly slow implementations which would be unusable in a real working scenario.
Is there any built-in solution in Maya's API, to handle what/how/when is cached in memory for a nodes' computation?
Is it something that I'd better implement myself from scratch, to fit the specif requirements of the node? Is it hard to achieve, being memory mainly managed by Maya?

4. Any existing basic example source?
Obviously, it'd be great to have an example to look at.
I'm currently looking at https://github.com/redpawfx/partio but it's taking a while to figure out where to look (@redpawfx if you read this, any hint is super-appreciated :) ).
But I must have chosen the wrong keywords while googling it, as I couldn't find anything useful so far.


I hope this post was not too long, and I didn't repeat concepts discussed elsewhere in this forum.
I tried searching for "cache" and found a few interesting discussions, but nothing specifically in the direction I'm aming to.

Thank you,
s  t  e
0 0
Filtering particle emission with attributes management
Quote: The MPx* classes are meant to be instantiated. Their compute (and other) methods are virtual and have to be implemented in the sub-classed nodes. So the way you are trying to call the emitter's ::compute method goes against all the established rules in the Maya API OO model

Thanks a lot for clarifying this.
I must admit that until now I was just interpreting the MPx vs MFn paradigm, more as a practical distinction between classes representing nodes and classes representing actions (well, I'm over-simplifying here, but you got the idea).
Also, having found very practical to sketch API code directly in Python, my C++ knowledge has remained a bit foggy and approximate, and I never really looked at how virtual methods work, before.
Definitely I'll have to catch up.

This will definitely help me a lot, in choosing between cases where its preferrable to extend an existitng node vs those where you want to implement a new one, instead, which manipulates data down the line.


Quote: It sounds like you are already doing some great progress catching up to the Maya API thing - looking at your kinect+fluids emission test

Thanks sir :)
Unfortunately, there's no API involved there (for now, at least).
That is purely done by converting Kinect data to a Particle cache, out of Maya, and then using the standard features to simulate the rest (plus SOuP for emitting the particles' colour into the fluid).

But now that you make me think of it, it will be definitely interesting to try write a cache node which outputs the recorded data, ditectly into the particle system.
I just need some time to get more acquainted with the API...
0 0
Filtering particle emission with attributes management
First of all, thank you for the superquick and exaustive reply. Very much appreciated.

Quote: From within your emitter you can generate any PP data, but unless corresponding array attribute is created on the particle shape node this data will not be used.

This bit of info was already useful :)
I was making a silly mistake while testing, and assumed I couldn't emit custom attributes, while it is indeed possible, as you say. I just made a more accurate test and that works like a charm!
That means I don't need extra nodes, at least for now, which is already very good news :)

Creating the corresponding array attributes in the particleShape node isn't an issue in my case, since the set of nodes is meant to be managed by scripts, via a UI, therefore I can make sure they exist before I emit into those.

As a side note, though, I must say I'm using a "filtering" MPxNode, not an emitter, right now. That's because I wouldn't re-implement the entire "emit from surface" features, which my tool relies on (I did a test and succeeded implementing the basic surface emission from sweptGeometry, but then I should have gone through the management of uniform distribution in world space, and I would avoid that if possible).
I say this, assuming I can't just extend an MPxEmitter and call its compute() from within my node's one.

In my custom emitter node I had tried (prototype is in python) something like:

def compute(self, plug, block):
    OpenMayaMPx.MPxEmitterNode.compute(self, plug, block)
    # here I would have added my custom code

That doesn't seem to work.
I read in the docs that the parent node's compute() can only be called by returning OpenMaya.kUnknownParameter, which wouldn't let me add custom code after the parents' emission has been computed.
Did I get this wrong?


Quote: there might be a way to obtain particle shape data in such way.
Let me know if you figure it out.


Because of the hint above, this turned out to be unnecessary, by now; but, since I'll have to deal with caching of temporary particle states and attributes, in the future, I'll definitely keep this in mind and let you know if I manage to produce any relevant result.


Quote: I hope i don't sound like salesmen here and that's not the point at all, but i have the feeling that SOuP nodes can help you with a lot of what you are trying to achieve - this can potentially shorten your development effort by a lot.

No worries, I appreciate the suggestion and, actually, having a look at existing SOuP nodes is becoming my default 1st research step, to figure out what can be done and what's the most approriate approach to solve a problem, both in terms of efficiency and in order to be in line with Maya's best practices in using the API.

The reasons why, in this particular case, I would rather develop a custom node are mainly:
* because I'm trying to contain as many custom features I can (I mentioned one, but there are many others that should be performed within the same emission), in as few nodes as possible
* because I really, really want to take this as an opportunity to finally study and understand the API a bit better, in order to be able to tackle more complex problems in the future :)

Anyway, SOuP is a constant reference, plus a great playground and inspiration for my experiments (an example here).
You have no idea how grateful I am for such a wonderful set of tools being available to all of us!
I know I just scratched the surface, but I'm equally sure I'll take more and more time to get to know it in depth.

Thanks again,
s
0 0
Filtering particle emission with attributes management
Hi everybody,
  I'm relatively new to the forum (even though I've been lurking for quite some time now), so please pardon me if part of this post might sound noobish or redundant to some of you.
I'm just starting with Maya API development for particles, and generally I'm not too experienced with the whole API development, too.

What I'm trying to achieve is to write a node (or a set of nodes) which lets management of particles emitted by Maya's pointEmitter, in order to leverage all the built-in features, still being able to add some additional logic to filter those out, and attach custom PP attributes to drive instancing down the nodes' chain.

The first test I did is a node to be placed between the emitter and particle node which gets the emitter output, and creates a subset of particles that then gets read and created by the particleShape node. That works fine.

What I would achieve now is to create custom attributes to be fed to the particle system too. Let's say for example I want to generate an instanceIdPP attribute, to use as indexing for particle instances later.

I'd ask here what's the best and most efficient way to do this (I would deal with big numbers of particles, therefore performances are important).
My main issue is that at this level I'm just handling freshly emitted particles, so I don't currently have access to the previously emitted ones (and their already-set attributes).

One thing I'm not sure of, is whether I might use the "instanceIdPP0", assuming it'll be automatically handled by the particleShape to store all the previously emitted particles' PP attribute.
Also, I don't know whether it would be robust enough as an approach, in that I'm not sure how indices in the attributes' arrays are handled (how whould they change when particles die? would new particles be appended or prepended? etc).
Finally, I'm not sure whether there's any feature of the MPxParticleAttributeMapperNode or any other MPxNode subclasses that I could leverage for this purpose.

I know this sounds quite general as a question, but since I have no specific experience, I'd ask you guys how would you tackle the problem before investing a lot of time (noob me, I'm still very slow when writing API code), implementing solutions that might turn out to be totally wrong.

I hope you can help me.
Thank you in advance, for this and for all the super-precious info you filled this forum with,
Stefano

0 0
Point Cloud import using SOUP

Hi, first post of mine here. I’m a total noob with SOuP, but I bounced into this thread attracted by the topic, since point clouds are something I’m getting more and more interested in.


sickiziu wrote: still can’t import *.PTS into Partio4Maya...

Did you manage to to that, in the end?

I don’t know if it's too late, but I wrote a simple script which should let you, at least, visualize a subset of particles in your Maya scene.
I shared it on a blog of mine, here. I’m planning to open a repository on GitHub to gather all the scripts I wrote so far, but this too will take time. Please refer to the blog in the meanwhile.


The script is obviously slow, but for visualization and testing purposes it should do the job.
Also, after creating the particles, you should be able to cache them, so the script is to be run just once.

The really slow section is the color assignment, which can’t be done at once, apparently (the emit command should allow this but when I tried, maya crashed).


In order to make the point cloud lighter, there are a few params that you can set:

  • start begins storing the cloud starting from the nth point

  • limit self-explaining, sets particle limit

  • factor subsamples the final particle number by a certain factor


I noticed some strange behaviour with nParticles, but with ordinary ones it should work just fine. Some friends of mine tested it with nParticles and said it’s working with those, too. Odd.


sickiziu wrote: -10.410307 3.049525 -1.842014 23 40 25 18
first three values are position [xyz], next color intensity, following three are [rgb] values

I wrote the script to parse a slightly different file, which didn’t have the intensity value; so you’ll have to slightly tweak the code to have it work in your case.


In addition, I can say that a friend of mine has developed with me a DLL which writes directly Maya nParticles’ caches.

Presently, the library is being revamped; therefore, we don’t have a clean version of the source code to share, yet. But the older version is available (and minimally documented) here:

http://blog.100cells.com/maya-cache-dll-project/


As a test, we chose to write a simple .pts to .mc converter using our library, and it seems to be working pretty fine.

We tested with a 300mb file (http://www.las-vegas.uni-osnabrueck.de/index.php/datasets/4-university-of-osnabrueck-elevator-and-corridor) and it takes around 2 minutes to convert it to a 10millions+ particles cache on my machine.

Maya doesn’t handle the particles too smoothly, but if you have enough RAM it won’t crash, either. We might share here the compiled executable (whats the forum-friendly way to do that, BTW?) but:

1. presently it is for Win x64 only

2. this too is to be generalized, in order to parse files with intensity (or ather attributes) values.


pechart wrote: Did you check Partio? Dunno if it handles the data correctly.

We were contacted by a partio developer in the past. Unfortunately, we didn’t have time to help integrating our cache writer into partio at that time; anyways, since we might want to reconsider that in the future, please let us know if anybody might find it someway useful.


Cheers,

s
0 0
count post selected

Add a Website Forum to your website.