Corona Renderer for Cinema 4D
Corona Renderer for Cinema 4D

grain

Cafe Oldtimer
  • Content count

    637
  • Joined

  • Last visited

Community Reputation

69 Excellent

1 Follower

About grain

  • Rank
    Respected community member.

Profile Information

  • C4D Ver
    13 Studio
  • Location
    London

Recent Profile Visitors

2,495 profile views
  1. That setup looks very nice and gives great results - just a quick one, you can do that contour rendering with Sketch and Toon as well. Lots of options to customise it but here's the basic setup.. Cotours.c4d
  2. Oh right well in that instance it will certainly help, particularly if you're basing your car scenes in a metro environment.
  3. Do you mean for modelling or texturing? The DEM map data that the plugin allows you to download is not super high resolution, by default the highest res it gives you is 30m per pixel. So when you're at street level the ground is blotchy and low resolution. Modelling wise, it's more useful as a guide for street and buildings in metro areas, but again, it's not super high resolution or detailed. Think the level of detail you get in Google Earth, it's similar to that, however the buildings are better in Google Earth.
  4. I GOT THIS Particles are dots in 3D space. Xparticles is great at moving dots around. It is powerful, and more important - relatively easy to use. I say relatively because it's still got a learning curve, and takes some to learn how to use it well. You can make similar effects in C4D using Thinking Particles but it's a lot more complicated to come up with similar effects, and much slower to learn. For another option, have a look at Blender which is free and can do particle animation as well. If you need to make particles in C4D then yes it's worth it. Floating license means you can use the Xparticles plugin on multiple computers (only 1 copy active at a time). Node-Locked means it's stuck on the one computer.
  5. Once you've cached the fluid sim and baked the mesh, it's pretty quick!
  6. Hah use corona then! When using standard renderer, does it take a long time before the render buckets appear (pre-processing) or does each bucket just take ages? Pre processing might mean you need to convert your clones to render instances, or use a mograph cache tag, and possibly cache any x-particles systems you've got going. Slow buckets is probably a result of the AO - AO is a real render killer, you should only use that when you really need it. Still, 1 hour for low poly stuff means something's not right. For that lo-poly / flat style with basic GI then all the newer render engines would be better, Corona, Cycles, Octane etc smash that stuff.
  7. 1 hour per frame is pretty crazy. What kind of things are you rendering? The answer to that question will heavily inform what render engine you end up going for. There's been a lot of discussion about this as there's a lot of different options out there. @Vozzz has written a guide at some point I think which would be good to check out. Without seeing what you're rendering, my guess is you could optimise your scene a lot to get the render time down before worrying about different engines or new hardware. Not sure what your experience level is but often when people are getting used to 3D they crank all the settings up rather than simplifying the scene, models, textures, lights down to bare minimum.
  8. Alembic is a cross-app standard file format for exporting animated elements. It's a more modern, robust FBX type format that allows you to export particles, splines, etc as well as normal polygon animation. Xrefs are for C4D only and can be really useful, but they require a lot of discipline across the team to use them properly. Also they used to be a lot more basic (but easy to use) and then around v15 or 16 they updated the xRef tech and now it's a lot more granular.. and I never use it now as a result. You can quite easily accidentally import the original animation into your file which negates the whole point of them. Alembics are fast and clean so they're better to work with IMO, except I think materials don't work with them.
  9. Export your animated elements to an alembic and then import them into the C4D file. Baked stuff is always huge but if you export it to an alembic it will be faster to work with in C4D. Plus if your scene autosaves etc it won't resave the whole alembic, just the C4D pointing to it.
  10. The polygons, points, etc aren't crazy. Have you got any mograph cache tags, baked objects, anything with a "cache" type option? 9gb is bonkers for a file unless you've got say a cloner with 1000 objects all baked for 2 minutes or something like that.
  11. Kiwi is a legend. Anytime you want to review a C4D version I'm sure we'd all love it. This review was more like a press release. I'm not sure what the point of it is, honestly, besides "C4D has some things! I am an editor."
  12. Looks like an awesome chip. I think it has fewer PCIe lanes than equivalent Intel chips, but not sure that'll be an issue. I am seriously considering building a system based on this tech as well. And, just in time, the geforce 1080ti has arrived. Good times. Also, the AMD Naples processors look like they'll be interesting as well. Sort of like the xeon version of Ryzen, 32 cores (!).
  13. Really cool stuff. Dare you to record a screencap while you sculpt your next one! Always love watching those things..
  14. Is that your existing animation? I can barely see any t4d in there. First, slow down your timescale, so it's running at say 10% that speed. That'll give your simulation more time to expand and fill the space (use a container to keep it stuck in the cylinder. Give that a shot and see how you go..
  15. They definitely look pretty good. It'll be interesting to see how they review and perform in the real world. Anything that gives intel a kick up the XXX is a good thing IMO. Unless you want to buy a multi-thousand dollar xeon chip the desktop processors have been languishing performance wise for a few years. My old 2011 3930k is still nearly as quick as my current workstation!