Jump to content

DeltaNacho

Registered Member
  • Posts

    6
  • Joined

  • Last visited

Recent Profile Visitors

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

DeltaNacho's Achievements

  1. One last update... I got it working! I had to toggle on "Indexed Attributes" and include the Normals attribute (N), on the SOP Import LOP. This same option would also need to be toggle on for the USD ROP. With the normal attributed indexed, Cinema4D was able to generate the appropriate normal tag! What gets me is that Blender / Keyshot didn't require this to pick up on the normals. Still odd, but it's working now and I'm not questioning it.
  2. Hey pals. Reading through this thread and it's neat to see some buzz about Houdini! I've been using Houdini now for over 6 years and cannot put it down! Here are a few observations and considerations, from my experience/perspective. 1. Houdini's overall software design makes it very extendable. Everything is a node. Not a cheap node representation of another element via a loose symbolic link. This modular design allows for SideFX to extend Houdini by new nodes as opposed to major overhauls. Yes, there are nodes in other software, but they are not at the core of the design, but another layer of extrapolation built on a pre-existing core. 2. Houdini is not a black box of compound operations, but also does not hold your hand. This is both a good thing and a bad thing, depending on the goals of the individual. If you are only concerned about high-level 3D artistry and making general pretty-pictures, there are better alternatives out there that will let you paint with broad-strokes, quicker, at much greater accessibility. 3. Houdini is not a plug-in centric software. If you need a feature or tool, Houdini makes building one VERY accessible to the user without having to write C++ code using the Software's SDK (still has that as an option, but not out-of-the-gate necessary). Contrast that with most other major packages that rely heavily on third party plugins. This is very empowering to the standard user, once you understand Houdini's paradigm fully. 4. You can perform most any operation in Houdini, as a standard user (no C++ plugin dev), that other DCC software can perform and much more! Objectively, Houdini is one of the most (if not the most) flexible, extendible DCC softwares, full-stop... BUT, do you need that level of flexibility? Only you can answer that question. 5. Very well put together Python API with awesome documentation all around. This makes Houdini a TREAT for studio setups and collaboration between other software. Here's my logic and perspective at a more personal level - If I'm going to spend most of my entire life learning a skill, trade that I am very passionate about, I want to spend my time/effort in the most open-ended solution possible (within reason). If I wanted an easy ride with a crutch, I'd be using Keyshot. I choose to live in a world of more absolutes, but everything in reality is in a spectrum (Keyshot => Cinemea4D => Houdini => C++ writing your own DCC). My goal is to be able to run Houdini just as quick, if not quicker than conventional DCC software. Houdini allows a user to not be beholden to the limitations of black boxed software. Hopefully this means unmatched industry maneuverability and much greater output potential. I do not want to be restricted by what the software will allow me to do. The real tradeoff is that Houdini's absolute control, brings with it much more complexity and requires more time to learn. Once you learn it though, a lot of doors open. Hope that helped a bit! If you are interested in Houdini, check out MOPs. Not a plugin per-say, but using Houdini's incredible extendibility to build up compound Houdini functionality - https://www.motionoperators.com/ SideFX has some GREAT training content - https://www.sidefx.com/tutorials/ Rohan Dalvi makes some excellent training content (free and paid) - https://www.rohandalvi.net/free Also... this
  3. Just an update for thread archival and the community... Igor and I had a look at USD ingestion into Cinema4D and we chalked it up to a bug. I will make sure to report it to Maxon. Thank you again Igor!
  4. Hey Igor! Thank you for taking the time to reply. Just tested and B => H / H => B checks out fine (minus the z-up in Blender flipping the axis - no biggie there). Please see attached for a .zip package. I do have access to Cinema4D and would not be opposed getting on a call w/ you if you think you have some ideas to try in Cinema4D (I'd screen share). Many Thanks, Clayton demo.zip
  5. Hey everyone! I'm trying to setup a data authoring pipeline from Houdini/Solaris to USD for Cinema4D, Blender and Keyshot ingestion. Currently, I'm having issues with getting appropriate normal tags into Cinema4D from the Solaris generated USD data! Any help would be greatly appreciated. Attached is a zip containing the Houdini scene and generated USD file. I also generated an alembic of the same geometry, from Houdini, to compare and contrast against. Here are some of my observations - Blender imports the Houdini generated USD w/ appropriate normals without issue. Alembic of the same geometry imports fine into Cinema4D, with correct normals. Importing the Alembic into Cinema4D, and then exporting a USDC from Cinema4D and importing in the USDC back into Cinema4D supports correct normals. Importing that same Cinema4D generated USDC into Blender, imports correct normals; However, when re-exporting from blender to USD again, and importing into Cinema4D, the normals are dropped. In short, if the USDC generated by Cinema4D, Cinema4D interprets the normals correctly. If the USD is coming from either Blender or Houdini, normal data appears to be dropped (no normal tags are generated). I hope I'm missing a step along the way or this sort of lack luster USD support in Cinema4D very much defeats the entire reason USD exists (to breakdown interoperability barriers between DCCs). Appreciate your time and input! Thank you. demo.7z
  6. Hey all, I have a question regarding performance when it comes to authored assets in an asset browser database. Some env details first - - Win10 - R26 Does it make a difference performance wise if I author an XREF object in an asset database compared to authoring a standard C4D PolyObject in an asset database? When you click and drag an asset into your scene from the asset browser, under the hood, the asset is a reference to something by default, so are there any performance gains going objects>XREF>Asset over objects>Asset? Isn't the asset more-or-less already being treated as an XREF from a referencing standard? Thank you for any insight.
×
×
  • Create New...

Copyright Core 4D © 2023 Powered by Invision Community