Wed, Nov 20, 2:45 AM CST

Renderosity Forums / DAZ|Studio



Welcome to the DAZ|Studio Forum

Forum Moderators: wheatpenny Forum Coordinators: Guardian_Angel_671, Daddyo3d

DAZ|Studio F.A.Q (Last Updated: 2024 Nov 20 2:21 am)



Subject: Upgraded RAM -- but very little render time improvement


Sherlock ( ) posted Wed, 16 April 2008 at 9:57 PM · edited Wed, 20 November 2024 at 2:36 AM

I upgraded from 1 GB of RAM to 3 GB. I expected to be able to render in 1/3 of the original time. However, I have not even knocked 50 percent off my original render times.

What am I doing wrong? Is there a way to tell D|S to use more?

Resource monitors show that I am now using almost memory (used to be at 75% during a render) and almost no swap, but 100% of my CPU is being used.

Any advice you can provide is greatly appreciated.

Thanks,
HL


prixat ( ) posted Thu, 17 April 2008 at 3:43 AM

You can try increasing the bucket size. (Do this in small amounts) This will reduce the disk accesses even further. But what you're seeing is about right. Sounds like the CPU was already getting just about enough data from 1GB. The CPU was and is the bottleneck in your system. :huh:

regards
prixat


Lighthorse ( ) posted Thu, 17 April 2008 at 9:15 AM

Ram ?? yea Right a lot of good it does
I have 8 gigs of Ram and windows only
sees 3.25 of it I have not figured out how
to increase that. The system sees it on boot.
But the almighty Windows will not recognize it.
Anyway My system is a Quad core with 8gigs
and a 1gig video card, renders are still what
they are, allot depends on your render settings.
I just found a small tut on render settings that might help.
Amazing what’s on google.

http://www.rubicondigital.110mb.com/Code/DSRenders.html

Lighthorse
FalconArts.Com


dvlenk6 ( ) posted Thu, 17 April 2008 at 11:15 AM · edited Thu, 17 April 2008 at 11:20 AM

More RAM will allow you to create larger (in terms of polygon count and texture size) scenes.
It might help some with render times; but for the most part, render time is [almost] entirely dependant on CPU power. There is also some minor fluctuations depending of HDD speed, RAM speed, stuff like that.
The major decrease in rendertime for having more RAM comes from having to access pagefile memory (which is much slower than RAM) less often.
The 'hardware assisted render' setting can use GPU (video card) cycles for part of the rendering process.

32-bit is 2^32, or 4 Gigabytes. Subtract reserved system (hardware drivers, OS req., and so forth) requirements and you get the total amount of physical free RAM. Every running program, even background processes, uses this free RAM; so subtract those req. also.
Generally, starting w/ 4GB, you end up in the 2.5 to 3.5 GB range.
Futhermore, unless you tamper with your boot.ini file; no 32-bit process will use more than 2 GB RAM each.
A 64-bit OS can theoretically 'see' 16 exabytes of RAM (~17 billion GB). Current 64-bit OS are capped at something far below that (128 GB for XP pro or Vistas above HP), which is still a lot more than you are going to be able to get into any existing PC motherboard.

If you have both a 64-bit OS and a 64-bit application, you can use up to the artificial OS RAM cap.
Example would be Vue 6 Infinite and 64-bit XP Pro being used together. You could then access and use up to 128 GB of RAM, minus system requirements, on a single scene.

Friends don't let friends use booleans.


Sherlock ( ) posted Thu, 17 April 2008 at 1:16 PM

I'll try experimenting with the bucket-size.

My CPU is a Dell Demension with a 64 bit processor 3200 + 2 GHz.
If that's a bottleneck, what do I really need to run this application?


dvlenk6 ( ) posted Thu, 17 April 2008 at 1:58 PM

The minimum system requirements are in the manual; but I get the feeling that isn't what you mean... :)

Friends don't let friends use booleans.


Sherlock ( ) posted Thu, 17 April 2008 at 6:26 PM

Sorry, dvlenk6, but you're right: that wasn't what I meant.
I guess I'll just have to be satisfied with the render times I have.

Maybe learning to better use D|S lights will help.


glennb ( ) posted Fri, 18 April 2008 at 3:41 AM

My experience is that you NEVER is satisfied with rendering times, the first times I rendered pictures I didt it on a 14Mhz 68020, that ws slow, today with 2.4Ghz C2D its still slow.. When the CPU/FPU is getting faster, you always tend to add other things, like resolution or effects, or just complexity.

The scene I rendered yesterday in DS took ~2h, at least thats better than 42h wich I think is the worst I have done yet (many years ago..)


Sherlock ( ) posted Fri, 18 April 2008 at 6:09 PM

Amen, glennb. So sad, but sooooo true!


FranOnTheEdge ( ) posted Sun, 20 April 2008 at 6:20 AM · edited Sun, 20 April 2008 at 6:20 AM

I've been rendering an animation in Bryce (- because I can.) 
And 1 second, 11 frames took around 3 hours to render at a size of 1024 x 576 (need that resolution to match video) - that's on a core2 QUAD, running win XP with a 8800 Ge Force GTS Nvidia card (at 2.4 GHz)

I am therefore trying out Maya to see if I can improve on those render times with the same models.

Measure your mind's height
by the shade it casts.

Robert Browning (Paracelsus)

Fran's Freestuff

http://franontheedge.blogspot.com/

http://www.FranOnTheEdge.com


Akhbour ( ) posted Sun, 20 April 2008 at 7:47 AM

Highend apps NEVER decrease rendertimes!

You always throw in some highend features like volumetrics, fancy particle FXs and such things, so you will end with the same render time or even longer.

My experience!

Peter


Kaji ( ) posted Tue, 22 April 2008 at 6:28 PM

Daz Studio is a 32 bit application. It won't take advantage of extra memory over 2, even on a 64 bit system. The Windows kernel itself takes up 2 gigabytes.

High end apps have faster rendering engines. I can render the same image in Cinema 4D and it will take fractions of the time as Daz Studio.



Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.