- This topic has 12 replies, 6 voices, and was last updated 2 months ago by
.
-
Posts
-
I’ve come to prefer Genesis 9 and would like to use it for the cast of my VN, but the only thing holding me back is the higher resource cost compared to Genesis 8 for group scenes. Is there a good way to bring Genesis 9 down in cost so group scenes wouldn’t be an issue? A group scene would be five G9s in this case.
Off of the top of my head...
•Hide all polys under clothing. In some cases, you could even delete unseen polys using Geometry Editor. If it ain't there, it doesn't need to be calculated.
•Reduce texture sizes as much as tolerable. You probably (definitely) won't need 4K textures on every surface. Turn off details such as bump and normals on non-central characters.
•Use Decimator to reduce polys as much as tolerable (but even just a few percent helps).
•For the overall environment, use inferences whenever possible.
•There's an option that allows you to replace the current figure in the scene. You could set up the entire scene with low resolution figures. Once the scene is composed to your satisfaction, replace each figure with your preferred pre-configured* G9 character. It helps A LOT to compose a populated scene using low res and then replace them.
*reduced polys, hidden polys, reduced textures, pre-posed, etc
With these considerations in mind, you could easily populate a scene with 5 or more G9s.
The problem with G9 (or any ray-traced engine) isn't polygon count. The amount of polygons doesn't increase memory usage or render time by any measurable amount until you get into the 10s-of-millions.
Textures use far more memory than polygons do. DAZ base characters and I'm sure many third-party characters also, use 8K micro normal maps. Those aren't necessary for any background character. You can remove those for background characters. You could probably remove them for any render that isn't an extreme close-up.
Any characters that have both bump and normal maps, you can remove the bump maps. For most characters, the normal map serve the purpose of the bump map. Having both of them active is redundant.
You can reduce the size of eye textures on any character that isn't extremely close to the camera. 4K for eye textures are unnecessary. You can reduce that to 2K and even 1K for background characters.
Ultimately, you want to reduce the amount of textures and size of the textures as much as possible. That's really what's using the most VRAM.Texture downsizing is a nice option, as others have already mentioned. Just keep in mind that with Genesis 9, micro-details take up the most VRAM because they are usually in 8K, while the base textures are mostly 4K.
I'm just saying that SOME of these micro normals and regular normal maps make characters look like their skin is like sand paper. I remove them almost always.
The other thing that can take up V-Ram is the Subdivision on any/all of the meshes in the scene. So I may be wrong about this but even having subd above 1 in the viewport takes memory. So I do all my viewing at a higher subd then before I render I pull the viewport subd down to 1 and the render subd can be at the higher amount. But I have to say that rendering at higher than 3 subd in my opinion is obsurd. Our machines are not ready for higher subdivision. So there is the Subdivision in the parameters tab but you can also potentially find high subdivision in the surfaces tab under the Displacement Strength. I always remove displacement except in extreme cases. Like there are some clothes that turn paper thin without the displacement/subd settings. But some creators are crazy they'll set that displacement subdivision to max at 12 and it will gimp your PC so hard.
Also if you're using strand based hair you have to be aware of the settings to use or those hairs will hamper any scene. They can be quite light if used correctly though. If you check your hairs surface settings and they have the settings cranked up to make the hair look thick it might be worth trying to tune it down for large scenes. For the card based hairs I might just be blind but I can't even tell when the normals/bumps get removed from card hairs. Some hairs can have 100's of shaders associated with them and if you reduce that you can save a bunch of ram that way too.
Everyone has had good suggestions I use these other methods as well.
Anyone rendering at higher than 3 subd is probably doing a cinematic for a video game or CGI for a literal feature film, where rendering can take a week+ for even a short video. If all you're doing are stills, it might not be as bad, but if you're adding filters, there's really no point after a certain number. I haven't done a full on high quality render in years, so I guess I'll get to find out how that all goes again eventually.
@jabaduhut Everything you said is correct. I just want to expand on a few things. The subd thing in the viewport using more VRAM is correct, because the viewport is rendered with OpenGL, and with OpenGL, polygon count definitely does make a difference. That's why high polygon counts in the viewport starts to make it lag a lot. That's also why it'll use more memory to store those polygons. For ray-tracing, while you're busy rendering, that doesn't matter. But, what you're doing, turning subd levels down when you start a render, that might actually help a little if DAZ doesn't keep the information in memory even after turning down subd levels (I don't know if it does or not, I haven't looked into that or tested it).
Other thing, with displacement; the displacement settings doesn't matter much if there isn't a texture in the displacement slot. It needs a texture to drive it, otherwise just turning up the displacement doesn't do anything. The reason some creators turn the displacement subd up to 12, is to get as many subdivisions as possible to try and get the most detail out of a displacement texture. I do agree that 12 levels might be a little excessive. In most situations, you could probably get away with 8 or even 6 levels.
Completely agree with bump/normal maps on hair assets that's made of hair cards. They have no real impact, unless you're doing an extremely close-up render at high resolutions.
And lastly, I also agree about normal maps for micro details. I hate them and that's not what normal maps are intended for anyway. That's the purpose of bump maps. Normal maps for micro details is what makes things look more plastic, in my opinion.
I personally use displacement for micro details, but I have a completely different workflow and structure, and I don't render with DAZ.Hey MaxTerrible thanks for some confirmation that I'm not completely crazy!
I've been wondering about something for quite a while now. Maybe you have some insight on it. So lets say I have a roughness map and I turn the slider for the roughness map down to 0 which turns the effect of the map off but I leave the image in the slot. Does that image being there effect V-Ram usage as opposed to removing the map in order to turn the effect off? Hopefully my question is understandable. My assumption that removing the map and turning the map down to zero is equivalent.
Leaving the map in the slot does keep the texture in memory, because it's still being used, just at 0 influence. Turning a property down to zero doesn't remove it from being calculated. It's just being calculated at 0 strength. To free the texture up from being loaded, you have to remove it from the slot.
That's good to know. Just another thing to chip away at trying to reduce ram usage. I appreciate your feedback.
To render a scene, you need to compose a scene first. That is best done with as little Active Viewport lag as is possible. If manipulating the scene becomes a slide show, there won't BE anything to render. With 5+ G9s, and God knows what environment, textures, props, clothing, and hair, lag will build. Thus the polygon reduction. Shave every insignificant bit. You don't particularly need to be concerned with memory for the final render while you are composing. By that I mean, once you compose the scene and save it, that memory will be freed up for the rendering.
Compose first. Save the scene. Restart/flush the cache. Render the scene.
I'm coming at this from a CPU only perspective. But it pertains to any system. Economics is key.
I haven't rendered anything in Daz for ages, so how does GPU handle things if that's even an option?
- You must be logged in to reply to this topic.
