Weird Carrara error ;)
Totte
Posts: 13,979
Decided to give Carrara some more love in my toolbox.
Been working on moving some of my figures for my render thread to Carrara and had set up a scene and saved and when I was trying to make a render on an obnoxious Genesis error C8.5 decided to crash.
When opening the scene I get this error (never seen that one before).
Any clues?
Edit: Mac OS X 10.8.5 btw
weiderror.jpg
509 x 164 - 22K
Post edited by Totte on
Comments
I have had it before
when content management service is not running
lack of metadata for the item can cause it too
only happens on DS4. duf content not Poser stuff.
Thanks, OK, then I know what to look for.
rather than start a new thread I decided to share today's new error
think the same Microsoft tiff security update that broke LIE in Daz studio for some with the tdlmake tiffs caused it
it was a .duf scene import from studio
this Optitex dynamic cloth scene https://www.youtube.com/watch?v=7tNxy-Q7eqo
ignore loaded it retry crashed it
I was also seeing a memory leak, Carrara ended up using 5GB RAM idle with just the genesis figure and dynamic cloth loaded
here is another when i tried to load genesis related character
Anything else in the scene? In my experience I see that when I bump up against the limits of my graphics card. Another possibility is a high value in the texture spooling. Try lowering that as far as you can. It used to be in Preferences under Imaging and Scratch Disk. Don't know for sure were it is in C8.5.
Try removing unused master objects, then remove unused master shaders. Then save it as a new file. When you open the new file, see if it still uses all that space.
Boojum
Here is another one. I inserted a text object. I used the character map from the accessories tab to insert a new character into the text modeler (AE). Worked fine so far. I then tried to convert the text model to a vertex model. Got an unhelpful error message.
Did you crank up the fidelity or change the defaults in the conversion dialogue? I had a similar error in C7 when I had the fidelity very high. I turned it down to about half-way between the default and maximum, and that helped give me a pretty nice model without the error.
The conversion error might not have anything to do with Dart's suggested extra characters in the text modeler. I recall getting an error in C8.5 when I tried to follow a suggestion of modeler conversions in the "five ways to fix poke through thread." If I remember, other people were not able to duplicate the problem.
Nice to see a different error message! :)
I'm betting that the DAZ developers didn't use asserts though -- the assert message came from the Microsoft C++ library. Most asserts are stripped out of the code during compile time; they are basically sanity checks for the programmers and the code is supposed to break when they fail.
I've said it many times before; DAZ needs to halt all new bells-and-whistles development and focus on stabilizing the product. Improving the error-handling so that it fails gracefully and actually provides clues as to what went wrong. Of course, I also think that DAZ is actively ignoring Carrara and cannabilizing its code for use in the Golden Child...but I digress...
Careful! People tend to misuse the term "memory leak" a great deal. Using 5 GB of RAM is not necessarily a leak at all.
A leak is where a program bug lets it hold on to a piece of memory instead of releasing it. The program then slowly (usually it is slow, a few bytes or kilobytes at a time) acquires more and more memory over time.
Based on your description, Carrara is just sitting there but with 5 GB of resources loaded into its memory space. That could be using up your physical RAM or it could be using space in your paging file on disk depending on the situation. Without more information, we cannot call this a "leak."
Careful! People tend to misuse the term "memory leak" a great deal. Using 5 GB of RAM is not necessarily a leak at all.
A leak is where a program bug lets it hold on to a piece of memory instead of releasing it. The program then slowly (usually it is slow, a few bytes or kilobytes at a time) acquires more and more memory over time.
Based on your description, Carrara is just sitting there but with 5 GB of resources loaded into its memory space. That could be using up your physical RAM or it could be using space in your paging file on disk depending on the situation. Without more information, we cannot call this a "leak."
A very good description of a memory leak. 3D content and textures do generally use a lot of RAM. I've seen both Vue and DAZ Studio hit my 32GB RAM limit on several occasions, will be interesting now when I have 64GB.
What really defines a memory leak is that memory that is not used for anything, for example if you close s scene but the memory it used is still there, it is leaked, or if you run an animation and for every frame you watch the amount of allocated memory grows, and continue to grow, and when close the document the memory is still used. Memory used for live data is never considered a leak as you cannot know what data is created and used for caching for example, so just because playing an animation increases the memory footprint of the application, it is not a leak by definition unless it stays allocated when the document is closed.
Yep, great follow-on post there Totte! When programming in Windows (and presumably Mac), you have things called "handles." Handles are just references to an object (an open text file say...or a bit of programming code). When you no longer need to use the object in question, you should "close the handle." This is often done automatically but sometimes things go wrong or code is written in a sloppy manner and the handle hangs around.
There are great tools (free! Sorry, Windows only...) available at SysInternals that let you look at your running processes and what is in their memory space. Process Explorer and VMMap come to mind immediately. They also make a command-line tool called "Handle" that will dump out a list of all the handles a process is using.
Yep, great follow-on post there Totte! When programming in Windows (and presumably Mac), you have things called "handles." Handles are just references to an object (an open text file say...or a bit of programming code). When you no longer need to use the object in question, you should "close the handle." This is often done automatically but sometimes things go wrong or code is written in a sloppy manner and the handle hangs around.
There are great tools (free! Sorry, Windows only...) available at SysInternals that let you look at your running processes and what is in their memory space. Process Explorer and VMMap come to mind immediately. They also make a command-line tool called "Handle" that will dump out a list of all the handles a process is using.
For Mac OS X there is Instruments which has a leaks mode, zombie mode and many others. A really nifty tool for detecting memory leaks. Also free from Apple with the XCode tool set.