Jump to content


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


Popular Content

Showing content with the highest reputation since 07/20/2019 in Posts

  1. 3 points
    perhaps just another thing you might be interested in - If you set some custom data as a delay timer , you can do a burn out scenario. I put a question for group and as soon as burning group is acquired, I start a countdown for custom data and if custom data reaches 0 I kill infected particles. So it burns for a while and then it is going to extinguish .... You can set some variation in burning length by setting range for custom data within emitter burning line 2.c4d
  2. 3 points
    Works using your approach if you are using groups. Emitter gets 3 groups and an explosia source tag but no fuel. Use first group only and paint with that. Now setup your infectio to change groups. Next importand step, all groups have to be changed to extended mode. This way you can set fuel to the last , the infected one only and it will start to burn along your infection... burning line.c4d
  3. 2 points
    Your thinking is correct. If you look at the emitter, groups tab, you´ll find 3 groups for the emitter and mode is first group only. The only confusing thing - I´m going to write a report right now - group particle paint has a blue colour while when painted it is yellow. Within paint, I have chosen the emitter and this first group for painting, just doesn´t match the colour and had to set particle age before painting. Now let´s take a look at infectio. As a colour mode, I set use groups and put in the other two groups from emitter (they have to belong to this emitter as it has the explosia source tag ! ) as groups to use for infection and incubation. As an incubation mode I set use "set from incubation rate" . This way incubating is progressing based on rate settings and this way incubation mod acts as a group change based on question/action would do. From seed object it is looking within set search radius if there is anything to be incubated and if there is, it puts it to group incubated as I named that group in emitter and put it to incubated group slot of the modifier. Infected follows accordingly and another group change to group infected is done (all by infectio mod, nothing you have to take care about). As this is the only group that has fuel ( remember I said all groups to extended mode so you can set physical data within groups) , it starts to burn now. .. Hope that helps to understand the principle .
  4. 1 point
    I'm using take system without problem. It works well. But I encounter the same problem one time in the complex old project. Maybe migrate to file to new project, it solve the problem.
  5. 1 point
    Hi All, I thought i would share my first real X-particles/Cycles 4D creation. It's a demo for a skin care product that never came to be... I was first approached to do a Flame composite and retouch for a film shoot. Long story short, the project died. So I then set out to make this demo with X-Particles. For me, having a project with direction is the only way to learn... Also timing seems to help because this would have been a lot harder to figure out without the "constraints" maintenance training. Cheers to that. Can’t wait for more videos! The only real issue I ran into was not being able to set an initial state on the first set of skin cells. Everything just blew up when I tried to apply it. Anyway, I just cached the full sim and only rendered what I needed. At the end of the day no big deal. thanks Insydium guy's for this creative outlet, KM SKIN_REVIALTIZED.mp4
  6. 1 point
    Unfortunately, it is not possible. You can use the object tag to hidden objects.
  7. 1 point
    you like some different colours for the spawns ? - Here you go 🙂 I love mapping - it´s done mapping spawn modifier... random spawn3.c4d
  8. 1 point
    and here´s another solution, maybe not as precise. Use a sub-question -> random probability. When particles are older than 25 frames they spawn with a random probability of 10 here random spawn2.c4d
  9. 1 point
    That´s what question for age mode -> fixed within range is made for. I set age to 38 range 12, that means if particles are aged between 26 and 50 frames they will spawn ... used a defined emission so you can see it clearly, a shot will work just the same of course. random spawn.c4d
  10. 1 point
    stick particles to object does work - but I think it is not what you want as you´ll get straight lines for the trails just as linear as the motion of the rectangle. From the turbulence involved, I guess you want those trails move just like hair. To do this , add a tendril modifier, make the rectangle to be the root object and set the desired tendril length . test_trail_tendrils.c4d
  11. 1 point
    sticking to the mesh could be done by covering and if you use nearest vertex you can kind of paint your spline... draw spline.c4d
  12. 1 point
  13. 1 point
    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.
  14. 1 point
    some things you can do 1) stack some emitters do get a decent flow and tweak some fluid settings (extended data) 2) you´ll have to set the radius higher to fill up more rapid, but you can do this after while when particles are within your container already. I eye balled that after 40 frames it is convenient to scale particles up. With an upper radius limit of 0.25 it will take a bit more than 130 frames for an overflow. With a max radius of 0.22 it will get you to use 175 - 180 frames for overflow, so you can adjust with that radius how fast filling should be completed. For that quick physical render ( don´t have octane) I used 0.23 pitcher-testing.c4d pitcher-testing.mp4
  15. 1 point
    Try increasing ray depths and bounces.
  16. 1 point
    yes , you are on the right track, however it needs another emitter for this. You set an emitter for shatter which is necessary for dynamics, ok. But now you need to add another emitter to dynamics tag. Set all group speed to 0 and then in this new dynamics emitter ask for speed to change group to which you will limit gravity. BulletTest.c4d
  17. 1 point
    somme tweaks later 🙂 ignition by infectioCY2.mp4
  18. 1 point
    and another, maybe simpler approach using infetio. Same emitter settings, it needs fuel within physical data and 3 groups this time. Groups extended mode, starting one gets none the other two need fuel. Now take care the the infectio seed object gets a position within the fire that you want to use to ignite . A PSR constraint can do this job. As soon as the infect is started by contact with the seed object, it starts to burn now . ignition by infectio.c4d
  19. 1 point
    Thanks Mohamed. Sounds like the only Cycles and Cycles 4D GPU solution on Mac will be NVIDIA (via 3rd party eGPU solutions — i.e. unsupported hacks), or a miracle occurs and Apple starts supporting NVIDIA cards with their next Mac Pro. But the writing has been on the wall for a long time between NVIDIA and Apple. NVIDIA initially caused problems when Apple was trying to drive OpenCL adoption so they're not totally blameless, but as I say no point in rehashing any of that now. Plenty of time has past since those days and since then Apple has given a big FU to anyone in the Mac community who wants to use NVIDIA hardware. Apple thinks Apple knows best, as usual. The ole "people don't know what they want until we show them" BS Steve Jobs used to say. Meanwhile fingers in ears, hands over eyes. Can't wait for their "modular Mac Pro" to show up and be exactly what no one asked for. Very likely some Thunderbolt-enabled cluster-F. Ultimately I think Apple's plan is to design and manufacture their own GPUs with help from TSMC, and I guarantee those won't support anything but Metal. A year ago PC seemed like an 80/20 proposition. 80% chance it was a smart move, 20% chance sticking with Apple / waiting for next Mac Pro was smart. Now that seems more in the range of 98 / 2 proposition. PC all the way at this point. Sad, really. All of this (with Apple's resources) was easily avoidable.
  • Newsletter

    Want to keep up to date with all our latest news and information?

    Sign Up