Jump to content


  • Content Count

  • Joined

  • Last visited

About c1p0

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Location
  • Interests
    There's a node for that.

Profile Fields

  • About Me
    [url="http://vimeo.com/c1p0"]Vimeo[/url]<br /> <br />[url="http://c1p0.hu"]Website[/url]
  1. I created a little xpresso script for subframe emission using thinking particles and custom data channels , i'll send it to you this weekend Of course this is still a linear calculation, the real solution would be to convert the previous positions to spline points, subdivide them, and get the point values from the subdivisions. Sounds like a complicated python script :S
  2. So what technique did you end up using? If you use dynamics, you can delay on the tag. If you used explosion, you can control the effect with the parameters. If you want to add turbulence to the dynamics, you should use forces tab , and keyframes to have the desired effect. You should narrow down what you're asking, so we can help:)
  3. I was thinking about the same thing, for null objects it can be done, but using a tracer to catch the motion and then emitting from the spline seems easier (since you'll have indexable points instead of frame based calculation.) I am trying to use the memory node with particles. Here's a simple scene with a very interesting problem: Scene File I'm using a ppass node, and i'm connecting it to a memory node (tp particle mode). I'm getting the data from both of the tp particle outputs. When i'm using the memory node to simply pass through the particles, the same particles are being created, (as you can see on the video). When i switch the memory node to output a previous state, the same particles are born again, bot the one from the memory node will place all particles to the same position. (this means that the pstorm node runs the same, but always get the first particles info only.) What i'm doing wrong? Balazs
  4. Hm. Interesting. I'm going to try out if i can achieve the same results. Basically this technique shows how you can make a lot of points between the previous and the current, and the velocity trick won't make any new particles. Thanks for the feedback, from you it's an honor
  5. Hello There! This is my first topic on mograph.net, so please be patient, and tell me if somethings wrong with this. Lately I've been talking to Chris on the CS-Tools topic about subframe emission, and I couldn't stop until i found a solution. This one is pretty fast and simple, and not using the velocity trick at all. I hope you'll learn something new from this. The technique helps you to understand the power of xpresso, which is nowadays got into the background because of python, which is of course far more powerful, but xpresso is underrated right now. I think i'm alone with this thinking, but adapting python functions as xpresso nodes would be great. Visual programming is the way programming should go (at least for designers). But to get on topic: What is happening here, is that xpresso is based on frames, so it is being calculated every frame at once(every frame the nodes are triggered). But nodes can be triggered with inputs as well, so this technique takes advantage of this fact. Based on the current and the last position, a number of positions will be generated, and being inputted (sorry for making up words) to the pstorm node, which will eventually run, and emit the particles, creating a fluid particle emission. I also show some pyrocluster optimization, but i'll make it a little more deep of you seem to care about this tutorial at all Best of wished to everyone here, and please don't be lazy, push some buttons on the keyboard and tell me your thoughts. I know I'm new here, but I really like this community. Found some very helpful/nice friends and coworkers here! Balazs Kerek
  6. Try asking Charles Rowland, he has done something with the object buffers to speed up workflow. http://twitter.com/#!/RagingClaw He has done python scripting. I'll try to get in touch with him and send him here
  7. Use the Multishader as Nick says, or if you want to get "dirty", use the per anders cloner script to get the objects from the cloner, then use an xpresso setup for iterating through the materials for each object.
  8. I looked at your file: 1. Your picks are way too complex (1200 points?!). You need like 7 for the calculation of each pick. That's why it's very slow. (use a simple polygon with extrude nurds then make it editable) Try optimizing your pick first, or at least set the dynamics calculation mode to boxes. also you can optimize by using the same effectors on all cloners. If you want to get close to the clones with the camera render, you should use proxy objects. (but you should not calculate with your current pick anyway). 2. If you want to modify each cloner with the same settings, you should use only one effector / type. 3. Also, Try using the same kind of cloning on all objects. right now half of them are grid arrays, half of them are objects in surface mode. This means you can't move the guitar together, since half the time you have to move cloners, half the time objects. This makes it almost impossible. So create a simple guitar instead, and use selections as objects for the cloner. Simply works better. I hope these tips help. I modified your scene, take a look here: scene file . This is using a very simplified pick, look how fast it runs (4-5 fps / sec), compared to your 0.0001 / sec
  9. Awesome. I ran into many problems with xpresso as well. Python is far more powerful. I know it will never happen, but the node-based system with python would be great. (i really like to see what's happening visually) One question: Do you know anything about subframes? And how to utilize it? I tried for a few times now, no luck yet. Thanks!
  10. Make sure all of the "forest" elements are aligned the same way. After that readjust your cloner using the transform tab. (probably you need to pull 30-60-90 degrees in 1 dimension. (most often case). If you use a null under the cloner, make sure your null object has a good starting position to the object you want to clone. Hope this helps.
  11. Try the Force parameter, and add the chains to exclusion? (this can work with cloners as well i think).
  12. Add the tag to your Cloner Object which is set to Object mode (drag your particle group in), and then make a rigid body tag, set it to: Collision tab Inherit Tag: Apply Tag to Children Individual Elements: Top Level Shape: to Box or Ellipse, if you have simple particles, or try modynamics(auto). If your particle is a moving mesh, set it to that (that's the slowest calculation) Force tab Follow Position: 10 - 20 Damping works funny sometimes, and it can make your particle to detach from the object, or get much slower then expected. You can turn down Gravity using ctrl-d and set gravity to zero. You can also apply forces through the dynamics setup, using the Force object list. Hope this helps!
  13. Wow, this sounds like the script of 2012 So you rewrote everything in python? That is indeed spectacular! Can't wait to see this system!
  14. By the way, if you use particles, and then use a cloner to make particles visible, you can use dynamics on the cloner, with follow position at about 10. This way your particles will move with the particle setup, but collide with each other. Hope this helps.
  15. You just need to set the Follow percentage to 0, if you don't want the matrix to control the "particles" any longer. That's when the Cloner can use it's own effectors to effect the particles.
  • Create New...