Leave a comment

I’m on (Sap)phire!

If you’re following this blog, you of course know about my obsession with lens flares and I’m sure you’re one of those guys who even have downloaded some of the free ones. Now creating these little buggers can be quite an ordeal and so I’m always hoping that someone will create “the ultimate lens flare tool” (no, Optical Flares isn’t it) or at least add more features to existing ones. Aside from some tweaks and the renovated preset browser this hasn’t really happened in Sapphire 8, but there are a few other nice things. I had a chance to play with it for a while now and you now can do  the same with the Public Beta. I’m gonna spare you the sales pitch, but in the long run the effects builder could actually become pretty useful. It’s just a bit rough around the edges and doesn’t really replace a genuine nodal compositing app, if that’s what you were hoping, but being able to stack effects in there and then only selectively expose required controls should make life a lot easier in After Effects‘ effect control window.

Leave a comment

The Freedom to be myself

Over the last few days there have been a few incidents where people gave me flak for stuff written here on my blog like my modo vs. Cinema 4D comparison or my opinions on MOX and I think it’s time to once and for all set a few things straight.

First, everyone have their eyes on the tag line of this blog. It says “The world as a strange place and my views on it.” Yepp, exactly that. If you come here for ultimate wisdom, then you have wrong expectations. All of what you can find here is my own personal opinion and my own nerdy, but still limited understanding of some things. I cannot tell you what’s wrong or right or what’s good for you. Hell, I often don’t know what’s good for me. You still have to make up your own friggin’ mind and at best use my own confused ramblings as a guide.

Second, I never made any claims or pretense that any of what I write here would be “neutral” or “objective”. To use a quote from my beloved Babylon 5‘s episode The Illusion of Truth: “The objective journalist is a myth.” So yes, everything is filtered, biased and colored by my own experiences and perceptions – just like your blog would be/ is. I leave out stuff that is not relevant or think that nobody is interested in just as I don’t tell you my darkest secrets.

Third, and that is probably the biggest issue, don’t assume I’m writing this stuff here just to ruin everyone’s day. The way I tick, I keep running this stuff through my head over and over again. That of course often means that I get lost in my own over-analyzing of things and appear as the eternal fountain of unhappiness because I’m never satisfied with anything or may even arrive at completely wrong conclusions. Add to that my awkwardness of expressing some things and not choosing the right words, some articles taking days and weeks to write and me simply losing track, not having enough time to investigate all details and you can imagine what a bloody mess this can be. I can only promise to try and do better, but I would ask that instead of picking apart my posts in pointless discussions on forums you add comments to them here or contact me directly and I can see how I can provide a more balanced view or correct stuff that is wrong. Also, just because I think that e.g. some feature in Cinema 4D is garbage doesn’t mean that I would be able to rewrite the whole program myself nor is it necessary. People all too often forget that you don’t have to be Rembrandt and can still be an art critic.

Finally, people often accuse me of peeing on their lawn for no reason. Do I? I don’t know. I don’t think in those terms. Yes, I don’t get along easily with other people because my mild case of Asperger makes it often extremely difficult to interpret the subtext of some responses and the other time I simply don’t care because the trivialities of life don’t interest me, scare me or are simply too confusing and overwhelming. The world out there for me is a strange place indeed. Still, I don’t think I’m a complete monster. While it may be a learned social behavior, I have actually reached a point where I get along with people and can start a conversation and joke around when I pick up my bread rolls at the bakery.

That’s also something some seem to forget: The virtual world is different from the real counterpart and there is a lot of misunderstanding due to language issues, cultural differences and other folly that ensues. Not everything should be taken that seriously – something that is meant in the best possible way can of course sometimes be offensive to someone when spoken with carelessness. Beyond that I have to take other people’s word for it – I’m actually easy-going and sometimes even funny to be around. I hope that wherever you are, you are, too, and that despite all the silliness you’d be the person to have a drink with after even the most heated shouting at one another….

Leave a comment

Mischievous Buying Spree

You have to hand it to The Foundry – when you think you have figured them out, they surprise you with an unexpected move. Buying Mischief and thus the underlying technology is an interesting, if surprising move. Let’s admit it – very few of us will even have heard of that app before. While the FXGuide article goes into some of the technical details, of course for us as users the thing that is most relevant is what comes of it and how we can actually use the technology to make our lives better. Some of the potential applications are:

  • Sculpting with almost infinite detail, both texture and volume based. Yepp, this could be potentially big and the demo embedded on that page is interesting. I would caution against expecting it to appear in modo too soon, though. There are a few other things that need to be ironed out firs in my humble opinion.
  • Of course the obvious use for all this is any form of 2D painting and I’m specifically thinking huge matte paintings and composites. With 4k/ Ultra HD becoming the norm even for more ordinary workflows and some filmmakers going crazy on IMAX you need plenty of headroom because your plates in post production need to be even larger than that.
  • Similar to the previous, of course large textures with almost unlimited detail come to mind. Be it just your ordinary slap-on UV texture or a sky dome HDRI, there is any number of uses for this. We all know situations where we zoomed into our 8k texture and it still looked crude. Multi-level OpenEXR files and LOD (level of detail) can help of course, but the memory demands, file sizes and other things like “jumps” between the detail levels are still an issue. Loading data more adaptively as needed could improve such workflows considerably.
  • While we’re talking EXR, the one thing that jumped to my mind immediately was deep compositing. Similar to the previous point one of the big issues with “deep” files is their huge size and all the problems that come from that like slow file access. Having smarter compression and data reduction no doubt could work miracles here.

There could be any number of additional uses, but we’ll have to see how this unfolds. I was also pleased to see Taron mentioned on that page. I worked with him on ZBornToy, if anyone remembers that little plug-in for After Effects a long time ago…

Leave a comment

XFroggier

Early last year I published some icons to make your XFrog objects look a bit more appealing in Cinema 4D and now I’ve given this another spin. I tried to make them even more consistent, but as always I could probably do another 20 variations and still not be 100% satisfied. I’ve also included XL versions to support high-DPI displays, but it seems the plug-in isn’t actually using them and resorts to the standard versions. I guess I’ll have to bug the XFrog people about it so they adapt their resource files. Head over to my download page to grab the good stuff and decide which version of the icons you want to use.

XFrog Icons

Leave a comment

Awesome Fusion

A few weeks ago the news of Blackmagic acquiring Eyeon and thus Fusion made quite an impact and everyone immediately started speculating that there would be a free of charge “Lite” version similar to Resolve or at least they would considerably slash the price so it becomes affordable. and what do you know? They did exactly that! Yepp, you can now get a completely functional version at the cost of exactly zero bucks. While they ripped out some features, the good news is that they left everything intact for compositing up to 4k. The stuff that is missing is mostly only relevant for bigger facilities and commercial production, anyway, so the Studio monicker of the paid version is more than appropriate. Otherwise you have plenty of cool things to explore and a pretty complete package. I’m not going to lie and pretend that I would not prefer that this was actually a free Nuke – there were are some oddities and quirks in Fusion that can drive you batty, but hey, for a free dinner I’m not going to complain too much. This is even more welcome since it now really puts pressure on all the others to make their apps more technically sophisticated (After Effects) or affordable (Nuke)…

Leave a comment

"Why are Humans afraid of us?"

After yet another dull week in the hospital I had on of those rare opportunities to get out and meet with a few friends and while zipping through the mall I ended up browsing a book store. There this little children’s book jumped to my eye.

Die kleine Spinne Widerlich

Die kleine Spinne Widerlich © Bastei Lübbe

The title translates as “A Little Spider named Disgusting” and this is going to make a wonderful present for little Tim who – like most children – isn’t really friends with those little critters. I love those cute illustrations and at 6 Euros for the CD-sized mini edition it’s an okay price. Love that stuff, anyway. I always have a hard time restraining myself to not buy every kiddy book just because of the sheer beauty of the artwork…

1 Comment

modo meets Cinema – another Year, another Version

Since last year’s edition is still an extremely popular post on this blog and we’re approaching the one year anniversary pretty soon, I thought it is time to update and revise it. If you know the old one, some of it will be redundant, but you will hopefully still find some of the info interesting, useful or at least amusing for its typos and bad writing. ;-) I have marked the paragraphs accordingly, so you can skip over the known stuff and focus your energy on the new info.

Cinema 4D R16 and modo 801 SP 2 were used as reference, and while some of it still is valid for older versions, you may find it more difficult to make up your mind. Too much has changed in both programs.

General Differences (unchanged)

Before delving into the details, lets take a more general look at the two programs with regards to their underlying paradigms and philosophies and how it will affect your workflow. Let’s start with modo.

Very much like Maya, modo is built on top of a command-centric engine. This means that each operation triggers some internal command. Those commands show up in a command history and can be accessed with the SDK. By modifying parameters within the command strings you can set different tool options or get different results from operations. This goes as far as being able to create icons/ buttons or keyboard shortcuts for different settings for the same tool. This will allow quick work once you have spent a little bit of time creating your own customizations. One further advantage of this fire & forget approach is that it allows the program to be relatively lightweight – you often can store only the command itself e.g for an undo instead of the result and the data an operation produces. As a downside this adds a certain intransparency and overhead. Data that has been generated by a command is not directly editable and will require yet another command to modify it. An extreme example for this is setting constraints or rest positions. When you edit a complex hierarchy e.g. for inverse kinematics you may end up assigning and un-assigning motion targets over and over while you tweak them. In a worst case scenario you may even end up rebuilding the setup from scratch because it is easier than fixing a botched one.

Cinema 4D is an entirely different beast. Its system is two-fold. Many modeling tools use a conventional edit and undo system. This part is not accessible by the user in any way and you have to live with the tools as they are provided and set their options as needed every time. This is one of the reasons why modeling can be quite a chore, but more on this later. The other part is the parametric part with all the dynamic primitives, generators, deformers, tags and all that. This allows you to keep things dynamic and editable and since many of these parameters are animatable as well you can create some quite interesting setups. On the other hand there is one big disadvantage: The more complex your scene becomes, the slower things can get. Traversing hierarchies and calculating all those parameters simply takes time. This can in particular become problematic while you work, but also has repercussions for animation and rendering. If you’re not careful you can run into all sorts of problems an inconsistencies such as objects that are supposed to follow others lagging 1 frame behind or their position being off.

Cinema 4D

Pro

Con

  • parametric items can be edited and adjusted as needed
  • many parameters can be animated
  • hierarchy order determines results of operations = good visual feedback
  • relationships between items can easily be changed
  • no command automation
  • repeating tasks require manual script programming
  • limited undo due to storing more data
  • limited customization options
  • full scene graph evaluation costs performance
  • odd and unpredictable glitches and behaviors
  • hierarchy-dependent evaluation can require structural changes to scenes

modo

Pro

Con

  • automatic command history
  • (theoretically) unlimited undo
  • customizable shortcuts, tool presets and UI elements based on command strings
  • re-use command chains to repeat complex operations
  • no parametric objects to speak of
  • parameter animation only on special items/ channels
  • repetitive extra commands to change item relations

Performance and Stability (updated slightly)

There is an persisting urban myth that Cinema 4D would be kinda unbreakable and never crash while at the same time modo would crash all the time. As you may have guessed, this legend is most prominently purported by users who mutually have not used the other program. So what is true and what is not?

Cinema‘s alleged immunity to crashes can mostly be attributed to its underlying processing model that often prevents hard crashes that kill the whole program. The program uses extensive threading to isolate different operations and process them in parallel. The interface has its own thread as do deformers, generators, the material editor and so on, so if one of those crashes or freezes, the attribute editor for a function or a panel may not respond, but you would e.g. still be able to save your work or even navigate around the viewport. Many times simply closing a panel and re-opening it would even bring things back to normal. So in a technical sense the program can still crash a lot, you as a user may just be lucky to not lose all your work. The one big downside with this approach is that you could end up introducing bad data – if you caused the problem by using excessive or wrong values, there’s a good chance those values will stick when the program has recovered and you could end up in a cycle of death where even touching a control causes the same mishap. Also the concurrent processing can contribute to the delay issues mentioned in the previous chapter.

modo uses a more conventional approach. This is in part owed to its command-centric architecture which requires things to happen in a specific order and as a result you may spend time waiting for the program to finish an operation before the next. This also has the downside that indeed if a single specific operation fails, it can drag down the entire program. However, over the years with each version the number of bugs and issues causing crashes has diminished considerably so unless you do something extremely stupid like creating a gigazillion instances of an item and thus exhausting all your system memory or using an invalid command string, it is actually pretty difficult to make the program conk out. At the same time this doesn’t mean that the program doesn’t know anything about threading. Dealing with instances and replicators, rendering operations, the preview window and other things are of course split to maximize efficiency. However, this threading happens in the context of the current tool or feature set, not globally.

A very crash-prone area as it turns out is importing and exporting scene data in both programs. In my trials with getting scenes and particles from Cinema 4D to modo or the other way around plus working on some CAD projects earlier this year I ended up spending a lot of time segmenting my data into sizable chunks to even make it work. In particular particle data and cached deformations make things go belly up and I’m still not 100% sure I have found the best way to deal with that, especially since for now modo does not handle multi-topology Alembic files (= files with different numbers of entities for each frame such as simulations produce them). Most of the time I was simply hacking it by using the X-Particles cache and the Realflow format, which modo thankfully supports. Another crash trigger is the introduction of the FBX 2014 libraries in both programs that more often than you would like produce incompatible files that freeze the apps on import or export.

Display Performance (unchanged)

Yes, we all live in a day and age where we all would like to swivel around in our viewports as fast as possible and not wait for a simple sphere to draw with several seconds delay like when I started doing 3D in the early 1990s. Additionally, we would like our viewport in shaded views to be as representative of the final result as possible. So how do the programs fare in this department?

There is no clear winner here. The problem is that to me modo feels “snappier” all the way and more intuitive, but does not bother much with displaying certain dynamic shading effects for procedural textures, shadows and so on. It relies on the render Preview for this (more in the Rendering section). It also has an added advantage because unlike Cinema 4D it does not need to evaluate dynamic objects and everything already exists as polygon data ready to be used by the graphics hardware. Also modo behaves much better with big scenes that have thousands of instances – that is if you can get over the program sometimes taking quite a while before actually having loaded the geometry. The chosen drawing type does not really matter since the program will be similarly responsive whether it’s wireframe or shaded modes. There is, however, a definite impact on display performance with deformation/ transform operations at the element level such as moving points on a complex mesh.

In contrast to this, there almost always is notable delay in Cinema even with some simple scenes because e.g. spline-based objects need to be converted to polygon data first before rendering it with OpenGL. In addition it tries to simulate many render features already in the viewport which cost additional resources. That may sound like it is superior in that department, but in my view the opposite is just true – it needs to do this because to date it does not have a decent interactive render preview. As opposed to modo the display type chosen definitely matters and sometimes in a rather peculiar way. A good example is working on my CAD scenes where there are literally as many lines as there are polygons. As a result, the more you are zoomed out and more lines need to be drawn, the slower things get. This gets even worse if you mix different drawing modes using display tags or you switch between different views with different modes.

On balance they both have their quirks and failures. Personally I prefer modo‘s approach – I like to keep things simple while I work and can go without the fancies as long as I get a maximum of performance. That doesn’t mean that the program couldn’t do with a viewport type that supports all textures and shaders ‘cos after all it might help to make it more attractive for realtime content developers like game artists, but for now it’s a low priority on my end. For Cinema, Maxon will simply have to figure out how to implement a sensible caching system do avoid all those drawing issues.

Cinema 4D

Pro

Con

  • viewport simulates a variety of shaders from the material system
  • considerable delays with scenes containing lots of parametric objects
  • sometimes massive delays when switching views with different display types
  • performance gets worse with many elements to be drawn

modo

Pro

Con

  • fast interaction even with large and complex scenes
  • chosen display type has little influence on overall performance
  • no delays when switching viewports
  • no advanced shading from the material system
  • notable performance reduction when operating at the element level (points, edges, polygons) on reasonably complex meshes

Interface and customization (unchanged)

Both programs have a reasonably clean interface that is pleasing to look at and feels professional using graphical icons on a dark grey background. At the same time both share similar failures. The icon design is somewhat inconsistent. In particular modo suffers from icons being way too colorful and each of the sub-sets having a different design philosophy. You can literally see how icons were created by different artists as new features were added with each version. To my own shame I’m guilty as charged since I contributed to this mess. I really need to sit down and come up with some good ideas and create a better set. Cinema 4D is a bit better but suffers from some icons having been revised with every new version, so things are becoming a bit confusing. In addition there is a somewhat ill-conceived attempt at color coding, which just doesn’t work. The crux with any such system is that you never have enough colors that a) can easily be distinguished to provide visual guidance and b) assign a color to each object type or function category. You simply will run out of colors long before you have come up with any resonable coloring scheme.

In terms of customizing the interface layout both programs offer the same basics like rearranging panes, creating tabbed layouts and placing icons. However, once you need to go further, things quickly skew in favor of modo. You can easily create completely new panels that collect your most used functions in the same place using the Form Editor, including full access to all standard interface controls. The downside here being that many of those panels are hidden in pop-ups, pop-overs and context menus, sometimes making it difficult to actually find them in the program when you don’t use a specific feature they are tied to. Without getting into Python or the API this kind of flexibility is not possible in the same way in Cinema. The only place where you can create custom interfaces is when you use User Data or create a new icon toolbar. Generally I also feel that Cinema 4D does not use a consistent methodology when and where to use what kind of control. Sometimes you will find arrays of checkboxes on one tool and then a pop-up to set similar options on another. An example for this would be settings for initial axes when you create an item.

There are also times when one will need multiple panels of the same type. Especially for animation you will often want to pin down or lock specific property/attribute editors, use multiple filtered scene trees and work in different graph editors on different animation curves. This is an area where modo‘s versatile and flexible form system beats Cinema every time. You can quite literally have an infinite number of the same panels and customize them as you need and whether it’s a toolbar, a viewport or a curve editor doesn’t make a difference. You could even go so far as to create instances of some default panels as separate forms and permanently derive customized versions. The only limitation is that you may run out of screen space and naturally your graphics hardware may not be able to keep up when you have to many viewports or other hardware-accelerated panels. Cinema 4D does not have full panel instancing at all, but in recent versions at least provides the opportunity to use multiple attribute editors and up to 4 Object Managers and Timeline windows.

Finally a few words on keyboard customization. This is again an area where modo clearly wins. You can quit literally assign shortcuts to everything until you simply run out. You can also define where a shortcut is supposed to take effect. Cinema does not nearly offer the same amount of control. While you can change a lot of key assignments, some default key mappings will never be available to be changed by the user. Because of this you can also inadvertently create assignments that result in odd behaviors because two unrelated functions respond to the same keystrokes.

Cinema 4D

Pro

Con

  • reasonable default layouts and shortcuts
  • no custom panels from scratch
  • only basic panels to store pre-existing icons/ buttons
  • sometimes conflicting keyboard shortcuts
  • not all options can be customized

modo

Pro

Con

  • flexible creation of new panels without additional programming
  • user can include his own scripts, commands and icons without additional work
  • multiple ways to display the same panel, allowing to choose the best method for a given situation
  • some layouts are too complex and overloaded
  • many hidden options that require modifier keys like Alt and Shift
  • many panels (forms) only accessible via right-click in not so obvious places
  • inexperienced users can be overwhelmed by too many customization options and actually destroy even the factory default layouts

Modeling (updated notably)

I started using modo as a replacement for Lightwave‘s Modeler when things there seemed to go down the drain. Undeniably this has ever since influenced my view of it. However, I dare say that when it comes to polygonal modeling, you’ll be hard put to find anything better. Of particular note here are the Action Center and Falloff options plus things like Background Constraints and the Workplane. All of these allow you to modulate the influence of your tools and align operations with your preferred axes. Another thing that contributes to this flexibility is the pretty good selection system in combination with the quick viewport navigation that allow you to pick the right elements. Ever since symmetry modeling got some major love in version 601 even that actually is fun to use.

Unfortunately, and this is where things get a bit dicy, while the polygonal and subdivision modeling tools are excellent, there is not much else there. Splines only exist as auxiliary items for extrusions or as guides and while there is an infrastructure for it, procedural geometry items are limited to what I would call tech demos for creating gears and some fractal structures. Some operations like Booleans also have a tendency to take quite a long time and produce some not so great results. And finally, modo still needs to work out its snapping logic, which most of the time is practically unusable. Nope, no longer true. At long last the snapping code has been rewritten from the ground up and it actually works in a way that is predictable.

In addition to the above, it’s worthwile making a note of some plug-ins that have further helped affirming modo‘s reputation as a go-to modeling tool. Yes, you guessed it, I’m referring to Mesh Fusion which at the time of release made quite an impression even on users of other programs. In addition to its powers the interesting aspect to me is that it also illustrates that parametric, editable and animatable modeling operations in modo are possible and it sort of provides a glimpse into what could be in store in the future. Of course I cannot go without also mention the Power Translators to import various CAD formats, but let’s not digress too much…

Cinema 4D takes a broader approach and can benefit from its procedural approach in some areas. Up to a certain point you are not committed because you edit a parametric generator object like e.g. an extruded text and not a mesh. If you know your way around, you can create some pretty elaborate stuff this way. The many spline tools will also help you considerably with graphical work for logos and other stuff that may have originated in a vector drawing or CAD program. The splines suffer from some issues with tangent continuity and shapes sometimes not being possible to close no matter what, but with a little work  like inserting some extra points this can usually be fixed.

In many cases there will however come the point where you need to Convert to Editable Object, meaning a polygonal representation for refinement and then things may not look quite so good. One of the problems you will encounter is that for many objects the program produces discontinuous geometry where for example the caps of an extrude object have a different topology than the sides and are not actually connected. However, it seems Maxon are realizing this and place more focus on creating clean meshes. The Symmetry object for instance has been “smartened up” and will now remove overlapping geometry and those pesky hidden points that would ruin your Phong normals. In addition, you can use the new Mesh Check display overlays to visualize problems as you edit the geometry. This makes it easier to get watertight meshes for simulations, boolean operations, texturing or the now en vogue 3D printing. Instead of rotating and zooming about to inspect the problem from different angles you only look at the colored regions and immediately get an idea on what to do to fix the problem.

Aiming in the exact same direction is the new Poly Pen tool. Initially I was quite skeptical about it since it seemed like just another knock-off of the various retopology tools found in other 3D programs, but specifically to Cinema 4D it really improves modeling workflows pretty massively and solves a lot of issues. Drawing polygons from scratch in 3D space is now easily possible and the same procedure more or less replaces the conventional Fill Polygon Hole and similar commands. In fact it makes them ten times better since the built-in snapping will avoid those ugly situations where you drew a point just slightly off and still had a gap that you needed to mend. The goodness doesn’t end there as there are options to split, bevel, extrude, merge and move stuff based on the current component mode or automatic smart routines. It can actually be quite fun to just doodle around – once you have developed a muscle memory for the multitude of modifier key combinations.

Despite these new tools, selecting points, edges and polygons can still be a major exercise. Sometimes you end up selecting not enough, other times too much, yet another time nothing gets selected and the pre-selection highlighting just flickers like crazy and you never know what you did wrong. The program also still doesn’t deal consistently with n-gons. They still get triangulated far too frequently when it seems unnecessary and you have to rinse-repeat edge-removal operations like Melt or Collapse way too often, only to find that after the next step you again end up with a clump of triangles on an otherwise perfectly planar (in human terms, not mathematically) face. Maxon still needs to work on that.

Cinema 4D

Pro

Con

  • parametric object and modifier types
  • comprehensive spline tool set
  • animatable modeling operations like extrudes or booleans
  • acceptable polygonal tools
  • reasonably working snapping
  • new in R16: Poly Pen tool combines many standard operations into a single tool with much better performance and more intuitively.
  • new in R16: enhanced Symmetry object and new Bevel deformer
  • parametric objects produce “bad” geometry once converted
  • program does not deal well with n-gons and arbitrarily triangulates them
  • subdivision modeling requires specific object type and is impaired by aforementioned issues
  • selection tools, including pre-selection highlighting, tend to be a bit wonky
  • some tools are redundant
  • limited options for soft selections/ falloffs and alternate transform axes
  • workplane and viewport alignment are lacking

modo

Pro

Con

  • refined polygonal modeling tools
  • native subdivision modeling supporting different types
  • falloff and action center system to limit operations
  • workplane and viewport alignment allow exact placement of items and elements
  • new in 801: massively improved snapping
  • no parametric geometry types worth mentioning
  • splines serve only as helper constructs for extrusion paths, text, deformers, replicators and so on
  • slow mesh edit operations like booleans

Texturing, Sculpting and Painting (updated slightly)

Of course when talking about modeling, we can’t leave out sculpting and (UV-)texturing. Sculpting has existed since version 301 in modo, but has only recently been introduced in Cinema 4D. As mentioned in the introductory chapter I don’t do character stuff, so my use for such tools is limited, but from my doodling around and occassionally “sculpting” piles of garbage or landscapes, they both seem to be similar in performance. However, naturally they are not specialized like Mudbox and ZBrush (nor were they meant to be)  and need to work in the context of a generalized 3D program, so there will be limitations.

An entirely different story is UV layout work for texturing. Once upon a time Cinema 4D took easily the crown with its texture painting and UV editing tools in Bodypaint, but ironically now has hopelessly fallen behind because nobody took care to keep the toolset current. Most artists these days prefer to do this work in other programs and then import the result. This unfortunately also affects procedural object types such as spline extrudes which generate implicit UVs. Converting them pretty much gives the same issues for the UV set as it does for the actual geometry. This also includes textures using the parametric mapping types like planar or cubic once they are made sticky as an UV set.

Luxology on the other hand have kept working on the texturing tools in every version and thus they are much more rounded out. Being based on “normal” polygonal tools, but operating in UV space they can be easily learned and used even if like me you only occasionally use them (as for technical visualization plain materials and procedural textures will often suffice). This also extends to workflows like retopology to rebuild a sculpted mesh as a clean mesh for animation, working with vertex maps and the preparatory work needed for baking textures.

Painting textures is possible in both programs, but given the already mentioned legacy issues is not as intuitive in Cinema 4D. Laying out the UVs simply takes too long to get there and then even being able to work on layered PSDs isn’t a saving grace. Being dependent on the Raybrush and test renderings to preview textures on multiple material properties also slows down the workflow. modo does the opposite. It much more emphasizes working quickly and getting a reasonably accurate preview with OpenGL and using the Preview renderer. As a downside, textures may need to be separate in multiple material channels and thus need more additional work in an image editing or compositing program to combine and refine them. In version 801 this has been somewhat simplified by supporting UDIM workflows that can assign textures on obeying specific rules for laying out UV coordinates and naming your textures.

Cinema 4D

Pro

Con

  • sculpting works reasonably well
  • implicit UVs on parametric object types
  • parametric mapping types
  • UV layout work is painful
  • texture painting not interactive

modo

Pro

Con

  • reasonably good sculpting
  • automatic UV generation on primitives
  • UV and topology tools based on standard tools and behaviors
  • good automatic UV unwrapping
  • intuitive and interactive paint system
  • easy and accurate preview of multi-texturing
  • more texture files to work with
  • usually more work with external texture editing for refinements

Animation (updated slightly)

Making things move can be quite complicated and not only involves creating the actual motion, but also involves additional processes like rigging, touches upon rendering and scene layout, may require simulation stuff and naturally builds on things mentioned before like good viewport performance and an accurate presentation of your scene. It even extends to seemingly trivial things like how well you are able to distinguish items in your scene tree or can manage visibility or their wireframe color. So by all means this is probably the most complex topic of them all and we only can cover the most critical differences.

The obvious place to start is by stating that I do only a limited amount of animation in modo at all. This has in part to do with some of the things mentioned in the General chapter. It makes a huge difference whether you animate an extrusion along a spline based on parameters or if you need to define two morph targets for the start and end of the extrusion, animate the morph blend value and possible need an extra deformer to conform it to the spline. Not only is it simply more steps, but it is more prone to issues like your extrude getting all wrinkled up when using a deformer. Similarly, the overhead introduced by using specific commands to determine relations or set values can become quite cumbersome while you prepare your scene for the actual animation.

The other part that puts me off is the slightly over-organized, highly atomized nature of modo‘s animation tools and associated editors. There is just so many places to go to do some simple things. One of those things I find quite annoying is dealing with deformers for example. They are split across the actual deformation matrix (the deformer item) and the influence item and then you can further modify them with additional falloffs, limit them by weightmaps and mix it all until you are trigger happy in the deformation editor. Things like the spline deformer will even add locators for its points and create its own group.

Now here’s the thing: I understand the advantages like decoupling the actual deformation from the parent mesh item, defining in which order the deformations are applied as well as avoiding unfavorable deformations by being able to explicitly define weight values and normalize them, but the whole system is way too complicated for applying a handful of bend deformers to do a page turn or wrap an object along a spline to create e.g. a snakey animation. This kind of very technical thinking extends further to channel sets, actors, poses, keyframe sets etc., all of which are great means of creating animation that can be put in assets, snippets and libraries to be re-used and swapped out as well as allowing the artist to focus on only the parts he’s responsible for, but in my world there is just never really time to use this stuff and benefit from these secondary organizational structures.

Which takes us to Cinema 4D. While it may not offer the level of refined control modo has it has one big advantage: It is much more visual. Yes, doing everything in the Object Manager is probably the biggest plus here. Instead of using a separate editor, you simply stack your deformers as needed and balance out their values, instead of creating tons of extra Nulls you simply reference a spline in a link field and instead of having yet more editors for poses, weightmaps, constraints and what have you you simply store that info in a special parent object or a tag right next to your objects. This is just bliss for simple-minded guys like me and yes, in the crunch it helps to keep things organized and understandable, too.

Does it have any disadvantages? Yes, of course. The simplicity in setting it up often comes at the price of requiring workarounds to actually make it work, meaning you often end up shuffling around items in the hierarchy, add additional groups/ Null objects or do crazy things like animating stuff in a “neutral” position and then funneling it to the actual place where it is needed using an Instance object. However, it still stays visual and once things have clicked with you and you know how to avoid twitching constraints or flipping Spline Wrap deformers it’s not that much trouble in most cases.

Moving away from these specific (but important) differences, the general toolset for animation is pretty similar. Both programs support animation of all basic transform operations, can animate single property/ attribute channels where possible, have constraints and Inverse Kinematics, deformers and morph tools are available and you can use audio for lip-sync animation and image sequences for backplates and animated textures. Cinema 4D takes this one notch further with its parametric objects which also can be used creatively for animation. A classic example of this would be an animated Boolean operation to reveal internal detail in a closed machine housing or drill holes (though it’s not necessarily the best technique for this due to potential geometry issues causing flickery animations).

Bringing it all together are of course the timelines/ graph editors/ dopesheets/ animation mixers. While they work reasonably okay, neither of the two programs really nails that part 100%. Personally I tend to think that Maya‘s editor back then when I used it was quite good and behaved the way I would want to. For the most part the editors in modo and Cinema suffer from issues in terms of a) fitting curves and keyframes in the viewport, b) tracking what’s actually selected in the editor and c) using sensible ranges to display hugely different value ranges of multiple curves, including resulting velocity curves. For my taste, one has to zoom and pan far too often to center the view to adjust a specific curve or move around a couple of keyframes. Not the end of the world, but you should learn to make friends with some keyboard shortcuts to automatically center your stuff or zoom in on the selection when needed.

For the new versions of both programs the leading motto has mostly been refinements to the timeline by adding specific marker types, comments and other such tiny-bitsy stuff. This is mostly relevant when you exchange files with other artists or work in larger facilities, not so much for one-man-shows. Similar things can be said about the changes to the respective Character/ Actor item types and elements, Morph tag enhancements and a few others – barely noticeable at first sight, but improving productivity, regardless.

Cinema 4D

Pro

Con

  • simple and intuitive handling of item selection
  • visual setup of deformers, poses etc. using specific item types and tags
  • animatable parametric modeling operations
  • complex setups may require extra hierarchies and objects
  • complicated animation mixing/ layering and retiming
  • hierarchy display options in the Timeline window can be confusing
  • unnecessary navigation in the Timeline in graph mode since view does not adapt to curve ranges

modo

Pro

Con

  • full quality preview for animation using the render Preview
  • image sequence painting
  • refined deformation and weighting control based on modeling tools
  • extremely convoluted setup options for deformers
  • bad visual feedback for constraints
  • lack of parameter animation for modeling and other operations requires extra setups and workarounds
  • extra navigation in the curve editor due to unfavorable value ranges
  • adjusting keyframe tangents can be unintuitive

Simulation (updated slightly)

Talking about simulation is going to be a delicate topic, mostly because modo has only had these features for a much shorter time and thus they are even far less complete than in Cinema 4D. Therefore this will mostly come down to a listing of the most common problems in both programs. So let’s begin.

In Cinema 4D obviously many of the simulation tools are old as in really old. Thinking Particles made its first appearance in version 8, reflecting the then current version 1.1 of the plug-in of same name for 3D Studio MAX. Ever since there haven’t been many notable changes and enhancements and when you consider, that Cebas now are at version 5 and how powerful this toolset has become, you begin to feel the pain. Similarly, Clothilde, the basic particle system and the Hair module’s guide/ spline dynamics come from the past. Only the rigid body/ softbody dynamics based on the Bullet physics engine are recent. But stay with me for a moment. While this may look grim, the tools are actually still usable and on their own actually aren’t that bad for simple everyday tasks. The real issues are other things.

First, the tools get slow very quickly. Yes, exceeding a certain number of particles can make Thinking Particles appear like it is frozen and this count is unfortunately only a few thousand, not millions. So forget about that ultra-realistic fire simulation. Similar is true for the other tools – using detailed models or complex interactions with lots of collisions renders them practically unusable. Aside from the tools not being multi-threaded this can simply be attributed to their old and not so optimized algorithms.

Second on the list is precision. Even if you use the finest possible settings and let your simulations do the number-crunching overnight, you will still many times see intersections of dynamic bodies or particles shooting through “walls”. This is in part since most simulation types do not use sub-frame sampling, in part simply the math used in the algorithms being too simplistic to deal with certain scenarios.

The third, and that’s one of the two remaining big stinkers, is that nothing goes together with the other. If at all, interaction between different simulation types can usually only be achieved by side-using specific tags and objects and often involves XPresso e.g. to convert some cloth simulation to points in order to pin an emitter to it. Each simulation type uses its own collision methods and associated tags also, which makes things like having a simulated rigid body deform hair or cloth almost impossible.

Finally, and that’s the real kicker, none of the aforementioned limitations would actually be that bad if there was a decent caching system, but you guessed it, it isn’t there. If it was, you could build your secondary simulations based on the cached data of the primary ones and then layer by layer create real complex stuff. You could then even apply deformers or use modeling tools to mangle and refine the data and you could use time-remapping to control the simulation timing. The good news is that this workflow is beginning to fall into place using Alembic, the bad news is that since it operates based on files you need to write them out to disk first and if something changes, you end up doing it over and over again. It’s not a dynamic system.

So in light of the above, does modo fare any better? Yes and no. As mentioned, its tools are perhaps one third or quarter of what Cinema has to show. The particle system is somewhere halfway between being a simplistic basic particle system, but since it already supports things like per-particle expressions (=rules) and custom data channels and can be wired in the Schematic View, it also is somewhat like Thinking Particles already. The performance is also notably better while previewing and, this is where it gets interesting, particles can interact with body simulations as well. This is achieved using the custom data and a handful of items like the Particle Operator. There is also support for basic fluid simulation and flocking, things you would only get in Cinema 4D with plug-ins like X-Particles.

The rigid and soft body simulation is based on Bullet just like in Cinema and as you would expect and offers the same feature set. What sets it apart from the other program is that there is actually a built-in global caching system for all of this which really helps once things get complex. Of course Alembic is also supported. This sounds all great, doesn’t it? But hey, not so fast. As you may already suspect from reading the previous paragraphs, it is all very technical and will take you a good time to master even some basics. This is even more so, since the documentation only covers the basics and there aren’t that many tutorials that cover this topic.

As a final note on this chapter I would like to add that it would seem interest from third-party developers to provide their plug-ins for modo is growing and some additional tools begin to appear. As a start the somewhat infamous emPolygonizer by Eric Mootz is available, allowing you to create real geometry surfaces (not just render volumetric blobs) from particle simulations with a smart UV coordinate reconstruction algorithm to allow all sorts of texturing tricks without having to rely on particle attributes like color. Not only is this in itself quite cool, but if you dig up info about Eric‘s other tools he created for the ICE framework in XSI you might get an idea what potential this brings for possible future tools. That said of course things do not look entirely bleak in Cinema 4D, either. X-Particles and Navié’s Effex toolset keep evolving and there is a notable selection of other plug-ins like Turbulence FD available. It really comes back to that modo feels a bit more accessible and powerful even with the base package.

Cinema 4D

Pro

Con

  • multiple different simulation systems cover a wide range of tasks
  • reasonably simple to set up
  • performance degrades quickly, so complex simulations are a pain
  • different simulation types cannot easily interact and require lots of workarounds
  • no unified caching system

modo

Pro

Con

  • complex particle tools, including a basic fluid simulation
  • soft and rigid body dynamics that can interact with particles
  • reasonable performance even with complex situations
  • unified cache system
  • difficult to learn and very technical
  • select simulation types not available an system still a work in progress

Rendering (updated massively)

Talking about renderers on forums is a recurring subject and in one such thread another user noted that there is no point in comparing renderers because each uses different algorithms, processing models and optimisations. That’s of course complete nonsense (or BS if you like) because otherwise people wouldn’t go looking for alternate renderers and just happily use whatever comes with their 3D program. There really is no need to make any song and dance about it as there are some simple criteria that define a “good” renderer and can be gauged by any user.

  • It offers good render quality.
  • It supports as many features as possible.
  • It is well-integrated in the program.
  • It is reasonably fast.
  • The settings and options are easy to understand.

That’s all that matters to the user. Anything else is just irrelevant academic blahblah because in the end we all only want to get some pretty pictures. Whether a renderer uses biased or unbiased, which global illumination method it uses, which antialiasing types it supports, if it uses CUDA or not or if it can brew coffee is by all means inconsequential to the artist.

Many of the observations in my article that started all this are still valid - Cinema 4D still has notable speed issues with things that in other renderers, including modo‘s, “just work” without dragging down performance. This means radiosity, transparencies with refractions and area lights still have a massive impact on render times. However, since R16 has introduced the new Reflectance shader model and various other improvements, it’s time to have another look.

First it’s worth noting that some of the limitations of using Hair and Sketch & Toon in combination with one another as well as standard render features have been lifted and the overall process streamlined. The performance is better and many of the redundant settings e.g. for antialiasing have been removed and now respect the global render settings. Other limitations like the need to let Hair generate geometry for raytracing still apply.

The real biggy is of course the already mentioned Reflectance system. While convoluted and a bit difficult to understand at first, it considerably improves the quality of the renderings. As I already wrote here, the beauty of it that it works within a closed system and you get that real bouncing of reflected light across different surfaces, nice “physical” highlights with good roll-offs and many other things. The downside, and that’s also something already written in that other post, is that it is builds on the old shader system for the rest. This adds an extra level of complication when bringing both together. The good thing on the other hand is that similar to the improvements in the modeling tools it proves that Maxon are recognizing the need for change and if they keep working on the rest of the material system and the renderer with the same level of sophistication and comprehensiveness it could actually be quite good one day.

With the specular and reflection system “fixed”, there is still enough else left to improve. I would expect a similar level of control over transparencies with all the trimmings like absorbtion, dispersion and at long last perhaps a sub-surface scattering deserving of that name and naturally improving the overall balance of the shaders and adding different lighting models are key. The absence of a native texture instancing or nodal system is also becoming increasingly painful since in order to exploit the strengths of the Reflectance stuff for instance you have to deal with even more texture slots. On the same note the lack of a truly interactive preview renderer also becomes more and more a point of concern. Many of the subtleties simply need to be tweaked in the context of the scene and not based on material previews that use spheres and planes.

The latter is a no-brainer in modo. It had the Preview from day one (that is when the renderer was introduced in 301) and ever since the introduction of RayGL in 601 even available to a degree as a normal viewport (you could always use multiple Preview windows in the past already aside from this). This makes tweaking parameters for lights and materials a pure joy. Since it’s integrated fully in the rest of the program, naturally you can even use it to preview animation and with all features full on. Even global illumination will preview at acceptable speeds and specific features like hair or particles will show up correctly as well.

As is evident by this, modo makes it a point to properly integrate everything to impose as few limitations as possible. This is achieved by making everything raytracing ready, including NPR rendering for instance, in favor of using specialized renderers or post-processing effects. One of the advantages of that approach is that everything works with everything, giving consistent results, and that in the long run even custom stuff can benefit from enhancements in the rendering core. If. e.g. one day global illumination got even faster, the hair stuff would simply inherit those routines. One of the areas that could use some of those optimizations is definitely the volumetric rendering. Some of that just takes forever.

One of the biggest criticism with modo‘s rendering and material system is the material editor. It’s one of those “looks good on paper” things to most people now. The problem here is, that its attempt at mimicking the Photoshop layer palette and applying material on “masks” works reasonably well for small scenes with only a handful of materials, but gets pretty messy when you have many of them and each of the materials has multiple textures in different channels. A conventional material editor or a node-based system that integrates with the Schematic View would be much easier. In version 801 first signs of this changing are visible. While there is no completely new material editor nor a full-blown nodal system, the developers have put their channel system to good use and provide a bunch of nodes that can modify parameters on textures and materials. This ranges from simple things like using a specific distance calculation to modulate intensity and colors or normalize texture sizes across uneven surfaces, but can also be used to create more involved stuff by defining rules what to do when a ray hits. The classic “make it look wet when it’s under water” by testing the intersection with a plane would be a typical example for this. It could also be of great help to throw in a little math if you need to make sure that for instance the Halftone material from the NPR Kit needs to retain a specific pattern size under all conditions.

The part to understand about all this is that it does not allow you to create completely new shaders like you would e.g. in Mental Ray, but, for lack of a better term, to smarten up your existing materials by making them “aware” of scene influences for which they do not have built-in controls. In the long run somewhat predictably we should of course see more features like that an a full-blown nodal system may not be that far away. In the meantime the already available options may help you wrap your head around modo‘s shading system being based on physical units. The advantage that it makes those values independent from things like scene scale or specific lighting setups comes at the price of being unintuitive at times and it takes a while before you actually know how bright 30 Watts per square meter are or how strong dispersion and absorption values in transparent materials need to be to produce a good rainbow coloring.

Quality-wise you can get good results pretty easy. The defaults are quite sensible for most render settings and defaults for lights and materials and it is usually easy to take it from there. However, once more modo‘s technicality strikes and instead of dealing with absolute values e.g. for rays per pixel, you tweak rates, ratios and thresholds and the program will then adaptively decide if and when to use which actual values. This can make you pull your hair out when you are trying to get rid of things like aliasing artifacts in fine textures. Some users also would love to see correct physically based materials in an unbiased renderer and noted that modo‘s materials don’t look real. That is of course totally subjective, because even physical materials can look fake when not adjusted right. I for one am quite satisfied with what I can get out of the renderer, though I’d never make claims to my representations of polished steel and sandblasted aluminium being 100% physically accurate. ;-) On a similar note, architectural people have pointed out that the renderer could do a better job at calculating the color bleed from colored walls and bouncing light that you get when using radiosity. This is again something I cannot verify, since I don’t do this kind of work, but seeing comparative renders e.g. with Maxwell Render there may be some truth to it.

As a last word to people who’ve been asking this: I cannot tell you that much about the respective network rendering features in both programs. Yes, I tried them in a geek sense just to see how they work, but never used them much in production. In part this is owed to the fact that much of my modo work was purely modeling or just rendering the occasional stills and thus it all happened on just one machine whereas on the Cinema 4D side of things the mish-mash of different versions and licenses we had at the office made it difficult to share files and use a unified NetRender setup. Often files created in another version would show differences due to bugs in Cinema like e.g. with Spline Wrap and MoSpline and at some point I decided to just leave it be and render each scene on its own workstation in the version it was created. Some heavier stuff we also handed of to a friend’s local render farm. Therefore my insights into these things are limited. I only know that TeamRender was unusable in R15, but R16 seems to have greatly improved in this department. My abiding memory with modo‘s distributed rendering is that it took forever to actually load files on the render clients, so in the end my main workstation had already rendered the frame before the slaves even had started. If I had really put it through the wringer, though, things might have shown a different picture and rendering sequences might work beautifully after the initial loading delays.

Cinema 4D

Pro

Con

  • basic setups e.g. for logo animation relatively easy
  • new in R16Reflectance system
  • new in R16: improved Hair and Sketch & Toon
  • overall bad performance and rendering speed
  • render times can vary hugely even with simple differences in settings or during an animation
  • different renderers cannot be used together
  • no usable preview renderer
  • no physical materials
  • materials require a lot of tweaking to look realistic

modo

Pro

Con

  • render speed is very fast for standard use cases
  • advanced features like global illumination often have a limited performance impact
  • render times remain predictable even in complex scenes
  • interactive tweaking of all rendering aspects using Preview
  • material system supports texture instancing
  • settings based on physical units, so they are independent from scene scale and complexity
  • new in 801: nodal shading via channel modifiers
  • material editor feels exotic and takes a long time to get used to
  • render settings are difficult to understand
  • radiosity could use some enhancements
  • energy conserving materials are still not necessarily physically correct
  • volumetric rendering can be extremely slow

Data Exchange and Pipeline Integration (updated slightly)

In this day and age artists use a multitude of tools to produce their imagery. Not only is it almost always common to refine a rendered image or sequence in image processing or compositing program, but also many additional 3D tools can be involved in the creation of an animation. 3D trackers could have been used to reconstruct camera motion and scene data of actual locations, external simulation tools may have been involved in creating effects for water or fire, characters and assets may have been created in a 3D sculpting program or modeled in another tool, animation may have been done using motion capture. Therefore it is crucial that programs are able to import and export 3D data as well as image data in a variety of formats.

Traditionally, Cinema 4D has been able to ingest a number of legacy formats such as 3DS, OBJ or Lightwave‘s LWO/ LWS. This is quite handy for me when I need to go back to some of my old projects and use parts of them. The LWO format is also my preferred format for exchanging geometry e.g. from CAD conversions since it supports things like n-gons, multiple UV maps and can retain entities/ layers by putting each mesh on a separate layer. As one would expect, modern formats like FBX also import well. In the reverse direction things don’t look half as good, though. In 20 years Maxon have not managed to fix their poor OBJ exporter and you either need Riptide Pro or must take a detour through another 3D program, which by all means could even be the free Blender. The more modern formats are not without issues, too. As you know from my render tests, transferring FBX files created in Cinema is pretty much a pain. Axes orientations change and there seems to be a lot of extranuous (custom) data that prolongs the parsing process and may make other programs fail on import. I have made similar bad experiences with Collada, which just doesn’t seem to work properly at all, at least not in the programs I use. The only format that because of its simplicity not quite unexpectedly can be exchanged with relative ease is Alembic.

One area where Cinema has been quite strong is integration with post-processing tools. Of course it has a multipass system and it can either render files with layers  and custom channels (PSD, TIFF, EXR) or spit out each pass as a separate image sequence. It’s still an insider gag, though, that to date the multipass files cannot have custom file names and you are limited to 16 object buffers. One thing that made big waves when it was new was the After Effects composition export that allows to transfer 3D animation as Nulls, layers, lights and cameras and also serves as a quick way to build compositions from your image sequences. It is now being replaced step by step with Cineware. Ironically, despite my involvement with After Effects, neither of the two has ever been particularly relevant. The stuff I work on is usually too heavy or structurally convoluted and before spending endless time baking keyframes, placing Nulls and whatever preparations may be required, I long have just manually done what’s needed. And before we forget of course Video CoPilot‘s Element 3D plug-in also can use C4D files natively.

modo pretty much offers the same features for rendering images in a variety of formats as well as loading and exporting geometry formats, but does the latter part a lot better. Yepp, the files you export from modo, be it FBX, Collada or OBJ are actually usable in other programs without jumping hoops. For rendering the multipass system is also more refined in that it ties in with the material system. This allows you to create specific passes based on masking items/ materials/ selections and you are not limited in their number unlike with Cinema 4D. Even manual material overrides are easy this way. In addition to the standard shading passes several analytical outputs are available that can help to identify rendering issues or can be used for further processing in compositing tools like Nuke. For the time being, 3D integration with compositing tools is somewhat limited on the After Effects end and only available as a Python script. For Nuke things look considerably better since it can import OBJ files and there are tools to import FBX as well. The Foundry also already have demonstrated using modo‘s renderer natively inside Nuke. Whether or not this tech demo one day will make it into a final product is however at this point an open question.

It is important to point out that now both programs also support color management via Open Color IO or conventional ICC profiles, respectively. This should make it much easier to get consistent results when moving your textures and rendered imagery across different programs and combining material from different sources.

Cinema 4D

Pro

Con

  • good import of 3D formats
  • probably overall best After Effects integration
  • complex multipass system
  • export of 3D formats unreliable and with technical issues; may require lots of manual preparation of the scene data
  • some unnecessary workflow limitations in the multipass system

modo

Pro

Con

  • 3D export works much better
  • Refined multipass system
  • limited 3D export to After Effects

The Future (updated)

Foretelling the future is of course impossible, but with regards to the two programs there are certain trends that are relatively easy and safe to speculate on. Things like supporting new OpenEXR formats for deep compositing are very much on the list for both programs as is the current race toward supporting high-DPI screens. Beyond that there are some pretty obvious areas that require development.

Cinema 4D is still dragging along lots of legacy baggage, but after the letdown that was R15, the new R16 is a major step in the right direction. Maxon just need to make sure they don’t lose their momentum and in addition to rounding out the renderer and material system do not forget to work on other things like better particles, cloth simulation or even more trivial stuff like making it play better with other programs by fixing the atrocious importers and exporters. I also still think Maxon are wasting their resources with things like Cineware and hanging on to their tiered packages. This “dark side”, if you will is really impairing a more holistic approach and causes fragmentation of features.

modo is making great strides and offers tons of features that others haven’t implemented yet, but has reached a point where it needs to take a breath and tackle some more fundamental problems before procrastination takes over. Better viewport representation of shaders is still on the list and things like the Viewport 2.0 in Autodesk products or this little plug-in called Element 3D give modo a run for the money and what you can do in realtime these days. Another area where modo lacks greatly is its attractiveness to third-party developers. Granted, it took quite long before such an eco system unfolded for Cinema 4D as well, but it seems that modo really struggles with this because the SDK is still not complete and fully documented, making it difficult even for experienced developers to get on board.

The Verdict (updated, of course)

The sticking point is that it’s still a good idea to have both tools if you can afford them and the more both programs evolve, the more I’m torn.

I love both programs, but regardless if I had to decide for just one I would settle on modo. It has reached a level of being complete and stable enough to tackle sizable projects and still tingle my geek nerves with stuff like nodal shading. Throw in the cool thing that is Mesh Fusion and when you need to do CAD stuff get the Power Translators you have a pretty nice package at a reasonable price. My biggest issue with it is probably that I have been so heavy leaning on Cinema 4D that I may miss a trick or two in modo that could make my life easier. I seriously need to learn it a bit better.

Cinema 4D is finally fixing some of its wrongs from the past. Will it be enough? That’s where things get a bit dicy since there are still so many loose ends. It always seems to me that they are still playing catch-up more than anything else. In fact I wish the Reflectance stuff had come out years ago. Would have made many of my visualizations much easier. That shouldn’t detract from the fact that the program is robust and reliable and you can do a lot with it and just like my rants about After Effects many of these niggles stem from the fact that I know these programs too well to overlook even tiny bugs.

In the end you have to pin down your decision on the details and how annoying their specific quirks and issues are for your everyday work. As someone having learned 3D the hard way 20 years ago, when hardware was limited and the programs much less powerful, I certainly have a higher tolerance threshold to some things. At the same time sometimes the weirdest things drive me up the wall. Currently the “annoying” factor for me is much bigger in Cinema 4D as I spend far too much time for my liking developing workarounds, thinking about the structure of projects or clicking around just so the Attribute Editor shows me what i need. I also can’t count how much time I’m spending shuffling around objects and tags in the hierarchy just so the program can evaluate parametric stuff. Not good for a program that is aimed at creatives. It begins to get frustrating when you have some cool idea and then can’t make it work because you have those things at the back of your mind.

In modo on the other hand I can just grind away with my work and aside from some performance hiccups when switching layouts or using specific operation never feel this aggravation. That is of course within the confines of the program – some tools are just not there (yet), so I’d never even work on some stuff that I do in Cinema. Still, this to me is probably what it comes down to: Working with these programs should be fun and allow you to take a straightforward approach to making your ideas a reality….

Follow

Get every new post delivered to your Inbox.

Join 46 other followers