Jump to content


The place to talk about X-Particles and Cycles 4D

Steve Pedler

  • Content Count

  • Joined

  • Last visited

  • Days Won


Steve Pedler last won the day on September 13

Steve Pedler had the most liked content!

Community Reputation

12 Good


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The hidden polys command only hides them in the viewport, so if you render the viewport you'll see that the hidden polys are rendered (using the standard renderer). Same is true if you use the IRR. Since the Cycles RTP is in fact rendering the scene I don't think there's any way to not render those hidden polys. The only way I can see to do it with the standard renderer is to use a material with an alpha channel set to pure black and restricted to the selection (scene attached). Then they will be invisible on render. Maybe you can do the same with Cycles. norender_hiddenpolys.c4d
  2. Steve Pedler

    XP trail THICKNESS and COLOR tab doesn't work

    Not at all, the reason is that you have set the spline parameters for the trail to have adaptive intermediate points. The problem with this is that Cinema then adds an indeterminate number of additional points to the spline, but we can only create thickness/colour values for each of the points we create. So there's a mismatch between point counts and the thickness and colour can't be used. If you set your trail to have no intermediate points, it will work as expected.
  3. Steve Pedler

    Use Particles to Trigger Emmiters

    You can do this with a emitter set to Trigger mode (that's what it's for). I've created a very simple file which you can look at, also see the manual for the emitter's trigger mode. In this file I've used a question to execute an action which triggers the emitter, but you can use anything which generates an action to do it - a collision, for example, or you could use the trigger action modifier to do it if you need a falloff. trigger_test1.c4d
  4. Steve Pedler

    Emit on Specific Frames

    There's no simple way to do this in the emitter itself, but it can be done with a bit of Xpresso. In the emitter, set Emission to Trigger and turn off the Pull Trigger switch. All you need to do then is have a little bit of Xpresso turn that switch on when you want to emit particles. In the screenshot, the Compare node simply compares the current time to 1 second (frame 30 on my system) and pulls the trigger when that time arrives, so you get a single shot at that frame. The scene is just an emitter with an Xpresso tag on it. Your Xpresso would be a little more complex because you want to emit on more than one frame, but you get the idea. Hope that helps, Steve
  5. Steve Pedler

    Circle emitter even distribution

    Not possible when using a Circle emitter. Instead, emit from the points of a Circle spline and check the 'One Particle Per Source Element' switch in the emitter. Steve
  6. Steve Pedler

    R21 Performance?

    You may have had confrmation of this from support already, but for the beneft of others this is nothing to do with XP. You have around 18 Python generators in the scene, all of which have to execute at the start of the animation, and that's what is causing those long delays. Turn them all off and it runs as fast as you'd expect. Steve
  7. Steve Pedler

    C4D R21 - MAC - FluidPBD, FluidFX dysfunction

    In the X-Particles preferences you can set the default mass to 1 (the factory setting is 1, on Windows and OSX in all Cinema versions).
  8. Steve Pedler

    What renderer?

    You can use Cinema's standard renderer to render particles and trails using the XP material but you will get far more capability using Cycles 4D, which is designed to be integrated closely with X-Particles. Other renderers which can render XP include Redshift and Octane although you may not get the same close integration as with Cycles 4D. We have never been asked to work with the Vray devs to render XP with Vray so at the present time I don't think this is possible, but you might want to check with the Vray people directly about this. Steve
  9. It’s perfectly okay to ask, but I can’t give you an answer. Not being secretive or anything, I just don’t know. I can’t really say more than that ATM, sorry.
  10. No, since then it would only work in R21 and be no use to versions earlier than that. We support down to R14.
  11. Steve Pedler

    Rotation in physics simulation

    This is behaving as designed. The particle rotation is set to tangential, so it will depend on the particle direction. Once they hit the cube, the direction is along the face of the cube. The direction doesn't change (until the particles fall off the end of the cube), so the rotation doesn't change. I think you're expecting the kind of rotation you would see if the spheres were controlled by the C4D dynamics, so they rotate due to friction with the cube. XP doesn't do that as it doesn't use polygon-based collisions, so right now this is the behaviour you will get with this kind of scene. You can use C4D's dynamics with XP (see the manual, there's a page about this) and then you get the desired rotations, but note the main caveat: once you do this, the particle movement is controlled entirely by the dynamics engine and not by XP's modifiers, etc. Hope that helps to understand what's happening here.
  12. Steve Pedler

    xpShaderFalloff Bug? SOLVED

    Thanks, I've found it now, though there is no layer shader there, just the xpShaderFalloff. The problem is not a bug, it's a serious limitation in the Cinema SDK. For any animated shader to work, they must be given the current scene time. For almost everything else in Cinema, you have access to the scene and therefore the current time. With the exception of (you guessed it) falloffs. With a falloff there is simply no way to get the scene time, it just can't be done. I remember spending hours on this when writing the falloff before concluding it was not possible. So animated shaders are out, I'm afraid. Re the other problem - PV render vs. the viewport render - my guess is that you mean the viewport appearance is different to the PV render, is that right? Because if you do an actual viewport render, it looks the same as the PV render. This is because in the skinner you have two settings, Polygon Size and Render Polygon Size. The first is used in the viewport, the second at render time. This lets you work with a low-poly mesh in the editor and a high-poly version in the final render, but as you found, if the render size is significantly smaller than the viewport size, the mesh can look very different. Make them the same, and the viewport mesh will look like the one in the PV render.
  13. Steve Pedler

    xpShaderFalloff Bug? SOLVED

    I can't find the layer shader or shader falloff in your scene file. Did you upload the correct scene?
  14. Steve Pedler

    stepping and lagging particles

  15. Steve Pedler

    Why Won't This Render? SOLVED

    This isn't a problem with Cycles, the same thing will happen in the standard renderer - that is, if you try to render the current frame to the PV, it won't do so. This happens because when Cinema renders an image to the PV (but not to the viewport, and not in the RTP of Cycles) it clones the current document then renders the clone at the specified frame. In many cases this works fine but for many dynamic scenes what gets rendered depends very much on the previous frames; data will have been generated and updated in those previous frames that each succeeding frame needs. This frame will then alter the data for the next frame. If you try to render a single frame to the viewport there's no problem as you're rendering the document present in the editor and all the data has been generated and updated. But if you render that frame to the PV, it will not have that data and so what you will get is essentially whatever was on the starting frame of the animation. Try your scene with the standard or physical renderer, you will see the same result when rendering a single frame. The solution, if you want one specific frame to be rendered to the PV, is to render the frame sequence from the start to the one you want. Yes, it is a pain to have to do that but it's the result of how Maxon implemented the external renderer (which is what standard and physical are considered to be when rendering to PV and why it's easy to add multiple render engines to Cinema).