View Full Version : Cinema 4D desperately needs a 'break' function.
04 April 2008, 11:36 PM
I find the biggest cause of crashing in Cinema4D, is when I mistakingly
enter a number that is too high to process.
For example, MoGraph's fracture object.
I had heavy poly object that I figured was worth testing.
Cinema didn't like the process and there's no option but to force quit.
What about a force 'break'?
I'm too busy to articulate in full, all of the other similar tasks that cause this problem, and I'm sure it's an issue in any 3d app. One without a solution though? Seems odd.
04 April 2008, 12:16 AM
Cinema shouldn't crash (i.e. stop working and quit) in that situation normally, just slow down a great deal while it does it's calculation (and possibly eat up a lot of memory), pressing the Escape key will often cause a break in C4D where possible. If you can be patient (and dependeing on how heavy a calculation that can mean waiting for quite a few minutes) Cinema will resume, and you can simply edit the value back again.
04 April 2008, 01:03 AM
To add to Per-Anders comments, Cinema 4D will often show "Not Responding" even though it is running perfectly well. This just means that it is involved in some intensive task that precludes user input. As noted, Esc can usually get you out of many tasks but it depends on how intensive the task and how often user input is checked (if at all).
This is one of those situations where one cannot be sure whether or not Cinema has gone AWOL or is just out for lunch and will be back shortly (eventually).
04 April 2008, 07:06 AM
To make an application react on an interruption you have to check for this in the code. However since this requires access to data from the OS every request for info will take some time that adds up quickly if the code is added to computing intensive tasks.
It's a tradeoff between calculation speed and control. More frequent checks for breaks can easily cost you several percent speed.
04 April 2008, 04:48 PM
What Kuroyme said pretty much goes for any program. I actually find macs more prone than pc's to this problem, but then again the macs i use are the older G4,5's.
The best way to prevent this is to upgrade your computer. Also another good precaution is to save before running any cache calculating. This has saved my butt many times. I try to keep my left hand planted on ctrl+S. This is actually true for any program i use, and especially with emails.
On a side note c4d is the least likely 3d program i have ever used to stop responding, and its the main reason i switched from 3ds to c4d.
04 April 2008, 11:12 PM
The best way to prevent it is to not enter too high a number to begin with. :)
Quad caps for NURBS objects are a constant danger for this. Lower the threshhold division number enough and you can be in for a loooong wait.
04 April 2008, 03:58 AM
All makes sense, I have a lack of patience in some instances, where it's taking longer than 2-3 minutes to resolve. I doubt it's a computer performance issue, I'm running a quad xeon with 8 gigs of RAM, which should be more than sufficient.
It's easier said than done to avoid these issues too, I'm sure we all accidentally add a number too many from time to time.
04 April 2008, 06:02 PM
Slightly off topic but... When Cinema starts to get choppy (not responding etc), i check my task manager to see if it's hogging ram or cpu and it always seems to show 50% processor use when working something like dynamics/pyrocluster or other non-render related tools... Is this due to some of cinemas code not using multicore to it's best?
04 April 2008, 07:25 PM
Some tasks can't be multithreaded. Especialy dynamical calculations are very limited in this regard. This is a very fundamental disadvantage of this kind of mathmatical problem.
04 April 2008, 09:11 PM
I run into this every time I halt a Sketch & Toon render while it's processing but before it's actually started rendering. As noted above, it's almost never a real freeze-up though. If I wait it'll clear itself and if I'm on a faster computer w/ more RAM it clears itself quicker.
04 April 2008, 10:32 PM
Some tasks can't be multithreaded. Especialy dynamical calculations are very limited in this regard.
Thanks shrek, thought it may be an issue with the systems i've been using :)
Does this mean that theoretically for complex calculations having a seperate single core CPU is more efficient?
04 April 2008, 11:16 PM
Not really. It's entirely dependent on the factors involved, some calculations are easy to distribute across multiple threads, others are much harder and may not reap as much of a benefit (and others still may slow down due to multithreading, often the smaller and simpler ones in fact). It's an area where the rules tend to be hazy.
04 April 2008, 11:16 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.