Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. I might be wrong, but I don't think Unity has a equivalent to Freeze Transformation. Try looking in Unity and finding where the Freezed Transformation would even be shown. It's kind of a cheat in C4D to get the axis of object to seem like it was zero by giving it a unseen parent. At least that is the way I think of it. Therefore, in order to get it to transfer the freeze transformation a null could be put as parent of whatever you want to have frozen transformation. Give the null the same position, scale, and rotation as the original before making it the parent. I'm also a little unsure why this would be something wanted in Unity. The final product is supposed to be imported into Unity. If you want something like this moving in Unity give it some joints and import the joint movement. It should move exactly the same. Program the movement to activate when x direction is pressed and that is how running is seen. Character animation in Unity is something to be avoided. In Unreal there are a few tools, but I still try to avoid it. I am unfamiliar with Unity though. Maybe the character animation in Unity is great.
  3. Thank you! I missed the Project Settings part, and google searching never mentioned that. Thank you Very much!
  4. pls refresh page - added info to my last post... CBR
  5. Please complete your profile to show at minimum which version you are working with. Have you changed the units in the 2 different places you need to - Project Settings and preferences / Units ? When I do this my grid defaults to 1 ft exactly. CBR
  6. Hi guys, I’m sculpting in c4d and when I bake my object, I’m getting these really jagged polygons when I render the baked object. Anyone know why this is happening? Thank you, D
  7. I usually work in Meters in C4D, but a recent project has required me to work in inches and feet. I have no problem switching the Units used in Preferences, but where my issue actually lies is in the World Grid. I desperately need a grid in 1 foot increments, but when I try to set the world grid to 1 foot it switches to 0.984 ft. In fact, it has an aversion to using the whole number I input until about 50 feet. Naturally working on a project requiring precise measuring and placement of things like wood planks for a real life project, having my grid slightly off is an issue. What is with this aversion to whole numbers under 50 feet about? Can it be remedied? Or am I stuck with essentially a useless world grid? Thank you!
  8. Today
  9. Yeah!! Lot of thanks, Mike. It works.
  10. Thanks for the replies guys. @danijelk that's not what I'm looking for unfortunately. I don't want to light my Fog with an HDRI. @MikeA Alright, thank you! I'll go ask in the Redshift forums although I don't have much hope... it's not a dealbreaker though. Still having loads of fun with Rs.
  11. If I'm understanding correctly, I don't think this is possible in Rs. I'd recommend you post on the official Redshift forums for a definite answer. There has recently been a major re-write of the Rs shading core to enable various new rendering tech, and I think that the whole area around 'volume rendering' is one that Rs acknowledges as weak, so hopefully this might get attention sooner than later. - but I would definitely check on the Rs forums.
  12. How are the rendertimes if you completely hide the glass spheres?
  13. Hello everyone, Im working with 2 IMacs to do distribution rendering. My question is can I have a third cumputer, not Imac and with windows system to have as a slave?
  14. It is difficult to give a specific answer to that, other than pointing to the unpredictability of subdivision when dealing with a mesh like this. That unpredictably extends to unreliability and inconsistency between renderers. When you are viewing in the viewport, you are seeing an open GL result which is optimized for display, and that happens to give a different result to when you use the Standard render engine, which is different to this. If this was a topologically sound mesh, I suspect they would look the same. Additionally I should also mention the flaws in Cinema's implementation of OSD, which is somewhat less than ideal, and may also be partly responsible in this specific case... for your general information it is best to avoid OSD altogether until you are an expert in how subdivision works. Standard Catmull-Clarke Subdivision is orders of magnitude more reliable, and should always be the first choice when working with SDS unless you have very specific, expert reasons for choosing OSD. CBR
  15. This is truly a thing of beauty. Thanks for sharing. I wanted a more childish finish to mine (the overall scene is all very low poly in feel), but not totally angular. I just could not understand why the viewport looked near to my vision but the render just wouldn't do it.
  16. You're welcome Don't feel too bad - these are the sort of problems that everyone new to modelling must face at some stage, and it's good to get them out of the way early in your modelling career ! For your reference, cars are generally best made with a technique called patch modelling, which is very closely related to regular SDS Poly modelling, but with a few key differences. Here is an example of a car made with stellar topology that will work absolutely flawlessly with subdivision because it gives the algorithm exactly what it wants to be able to work. Note the polygon density, the evenness, the regularity, and the lack of even a single triangle or complex pole... CBR
  17. No...you are correct (though that would be wonderful). My point is that while I love Embergen's interface and quick viewport feedback, the fact that it exists as a standalone application outside of native C4D is not a better solution to using X-Particles within C4D. Just look at the two workflows: Because X-Particles works within C4D, you have a lot more control in how you can sculpt the fluid simulation and have it interact with the objects. Quick iteration is possible all within C4D. With Embergen, I am not sure how much particle control there is but any changes made to the C4D objects or their animation requires that you have to re-export/import back and forth between Embergen and C4D. Given that the last steps of both workflows are the same (VDB creation and shading --- though I do think caching is "slightly" better than export/import), then what is the advantage of Embergen over X-Particles at the start of the process? X-Particles provides some incredible control, works with fields, allows mutli-physics (gaseous simulations on top of fluid simulations on top of dynamic simulations as well as volume breaking, grains, etc) - and all within C4D so that you can iterate quickly. At some point, Embergen will be able to export particle velocity data which will be able to be read by Octane---but only for rendering of sparks (as that was all they talked about in their live stream). With X-Particles, you can create a fluid simulation and use the particle velocity data to drive a cloth simulation with tearing. So you could create a gas tank explosion that rips apart the body of the gas tank realistically as they are all driven by the same fluid dynamics creating the fireball. And, as everything exists in C4D, you can tweak and fine tune all those dynamics real time before rendering. With Embergen, you would have to cache the physical dynamics first, export/import into Embergen, add the fluid sim and hope you don't have to make any tweaks to the dynamic simulation. Sounds painful to me. And lets not even talk about X-Particles ability to use UV maps, infectious growth algorithms and fields for managing what happens as the fire spreads across a surface. As Embergen matures (and it will mature), the level of interactivity to create this type of X-Particles simulation (seen here) will be possible but just so much more painful in Embergen. So....for me.....while Embergen has advantages it really is NOT a better overall solution than X-Particles. Now...if it becomes a fully integrated C4D plugin or is bought out by MAXON or Insydium, then things change but that is a long way off and more than likely will not happen. Dave
  18. ps for my own knowledge (and sanity) - why is it that the viewport looked nearer to what I wanted, but the render did not?
  19. Thank you for your feedback Cerbera. I did start it as a low poly project originally, and then just expected an SDS to work when I decided I wanted a smoother overall finish, now I see I'm clearly being naive! It's very early days for me so it's great to get such detailed feedback from a veteran. I'll go again with the body. Thank you
  20. Oh it's to do with illegal topology. You don't seem to be aware that you can't use subdivision surfaces with triangles, complex poles or ngons and expect a predictable result - this is one of the primary rules of SDS modelling - you require an all-quads model, with even, regular distribution of polys and decent edge flow. Unfortunately this model has almost none of that, meaning that you leave it almost entirely to luck whether SDS works or not, in this case it doesn't, and can't until you fix the mesh ! In fact this mesh has some fairly fundamental problems, and is not nearly enough polygons to describe the form, and I'm afraid at this stage is eminently unsuitable for use with any kind of subdivision. CBR
  21. Thanks for your responses. I have attached the C4D file, only the car model in there. I did try a number of different Subdiv settings but I'm a complete newby so am likely to be doing something wrong.... Thanks again, Chris Car ex.c4d
  22. This is almost certainly something to do with OpenSubdiv settings, but unlikely to be a bug. Like everyone else here we need the scene file to be able to tell what is going wrong. CBR
  23. Fundamentally what's happening is that the displacement is distorting the texture mapping - so the texture is shifting / swimming on the surface slightly. To fix: Look in the Rs object tag on your sphere > Geometry > Reference section - right at the bottom. Set to Object and then drag your sphere into the object slot. I think that should fix it.
  24. Curious. The subdivision for editor and renderer is set to the same value, so the resulting image should be the same. The Standard Renderer does not have render setting options to switch SDS off, either. There is no animation on the SDS, and the timecode for both screenshots is the same anyway. Doesn't seem obvious to me... Please send a (reduced) scene file. In the meantime, what happens if you switch the SDS to another type?
  25. rfanoni

    Wrinkles and Folds

    I wonder if you could use something from this technique as a starting point:
  26. Your fracture is changing the amount of objects within itself as it animates so inevitably some colours will change as you have them randomised and the index for each element will change as new pieces are added and removed, and pieces are probably colourised using that index no. Im not sure you can keep the random colours as long as your changing the number of pieces. Not sure how your example was done. Deck
  1. Load more activity

Latest Topics

Latest Comments

×
×
  • Create New...