Daz3d Decimator

[Matilda Equiluz]

Im considering getting the decimator plugin, and I've looked through as many forum threads about it as I could find, but a lot of them are pretty old, and opinions are varied. Just wondering how the plugin works in DS 4.10 or 4.11 beta? Also, considering that it's mainly the textures that eat up resources, is there really much of a gain to be had vs just brutally reducing/removing textures from background characters or vehicles etc - I'd only really be considering using it for background characters that would be out of focus in a large city street scene for example.

I've been messing around this morning, removing and reducing in size as many textures as possible from figures and clothing, and I with a selection of figures with different poses and outfits, plus instances of each of them, I found I could create bigger crowds of characters than I'm every likely to want.

I was only looking at the Decimator because it's one of the 80% off items in todays sale, but there's also the cost of a new release that I don't really want (at least not at a measly 30% off) to factor in, so the Decimator isn't quite the bargain it looks at first glance.

The decimator plugin was made so that meshes and textures could made game ready. Its not needed with Genesis figures since they have sub division levels that can be changed as can a lot of clothing and hair.

For striping a scene down, I have a product that was made just for that - -saver-shaders-collection-for-iray - At the very least, read over the info in the promos for the useful info about textures and meshes. There is also a thread about it here with additional info - -saver-shaders-collection-for-iray/p1

I find decimator essenial for a couple of uses. For instance, if I need to reduce a crazy number of hair polys for simulation. I also use it on distant figures in crowd scenes. It's great to combine with other tools (like @Mattymax's product) to get your scenes to a reasonable level.

its good for reducing mesh poly of characters, and high ploy props making them ready for game and animation, its really handy for saving on 3delight renders reducing the geometry mesh. but like Matty said its not need as much now if your using genesis and iRAY. i would recommend and would properly buy Matty's Shader/texture resource savers first if i did not have it already, it will save you a ton of time reducing textures and removing bump maps which are a resource killa for iray

When I need a MDD animated figure mesh to interact with the fluid dynamics of Realflow

I use a heavily decimated version as a "stand in" before sending my scene over to Realflow

For Liquid simulations

and replace him with the full res version for the final render in C4D.

I bought it and for some models it could decimate to as little as 5% - 10% of the original polygons and still look quite decent in Unity using Unity's built in subD. Those were vehicles though with already a lot of flat surfaces that lend themselves to decimation quite well; tires looked clunky as you'd guess. Unless you are building a game with a large number of different models in it, it's not particularly always needed to decimate at all, just export at base subdivision level.

For almost every model I tested you could decimate to 40% - 50% percent of the original polygons remaining before noticing big differences. Newer more capable HW and SW though makes decimation less and less needed for the typical small game without a lot of assets used in it produced by hobbyists.

I came across it in someone's essential tools post, but then realized it was an old list. Is this still useful with gen 8 and 9 products? Do newer products like -optimizer pretty much perform the same role but better?

I own both, but I use Scene Optimizer far more than I use Decimator. That fact is that reducing the poly count is really not that important compared to decreasing texture sizes when it comes to the usage of both RAM and VRAM, which are the main considerations when optimising a scene pre-render.

Most modern renderers and game engines can efficently handle huge poly counts now, which was less true in the past. Scenes which needed a lot of polys, like nature scenes with a lot of trees, grass etc, will use instancing to reduce resource usage.

I sometimes use decimator to reduce the poly count of an outfit I have converted to dForce (ie one that was not created as a dForce item). I find that high poly clothing can take a long time to simulate, particularly anything with more than 30K polys. Decimator can reduce the poly count in this case, and help speed up the simulation.

I just bought the Decimator... Great price I couldn't pass it up. I'm thinking it will be useful for crowds of peeps.. etc... and I'm getting some pretty unusual shapes on figures. We shall see.. ENJOY this sample... it's -for-genesis-9 with Decimator at 10%... It takes away a lot of the detail but for a far away render I kinda like it :)

I never catch any good sales... no matter what, I find out the day after or in a thread where people are celebrating their good fortune and I'm the sad vagrant looking in through the restaurant window at them feasting...

... reducing the poly count is really not that important compared to decreasing texture sizes when it comes to the usage of both RAM and VRAM, which are the main considerations when optimising a scene pre-render.

Absolutely correct. The same way that instancing will lower the amount of resources used, not so much through geometry duplication but texture duplication. Comparatively, texture load is by far and away the major GPU hog compared to geometry.

Depends on the item, usually and for most of the assets, there is no need for the Decimator, but... Then there are items with astronomical vertex counts, talking about millions of vertices for something insignificant and relatively small.

Decimator can fix these items, otherwise the only real option is to remove them from the library.

Yeah. Inefficient UV mapping is a problem and sometimes inefficient UV mapping can be caused by an effort to efficiently use small texture sizes. The one situation I'm particularly thinking of is my little arch bridge ( -bridge/p1) To get small textures, I had to tile the texture. To avoid distortion of the texture I had to do a planar UV map of the side of the bridge meaning it was much wider than it was high. Basically the side profile of the bridge in UV co-ordinates was 0to1 in X and 0 to 0.3 in Y. Seems highly inefficient, but would be difficult to counteract texture distortion completely correctly if I did it 0 to 1 in Y.

Did manage to find a way to use the same straight block texture used on the sides around the arch and underside of the arch, so that felt moderately efficient. And I think the bridge only had 150 facets or so.

If the image size of the textures using the UV are relatively small, the unused area on that texture image is not that big of a problem, but when the product starts using 8192x8192x24bit images which eat 192MB's of RAM per each image (irrespective of the file format or the size of the file on disk), that is when the unused area of the images quickly becomes a problem.

The worst case (so far) that I have seen, was a surface that had five images attached to at 8192x8192x24bit per image => Total usage of RAM was 960MB's (and 480MB's of VRAM)

When I looked at the UV mapping of the surface, only a tiny fraction of the image s were used anywhere on the model, and the RAM usage for that part of the images would have been 20MB's combined for all of the five images.

Like the title says, I'm currently opening a request for the updated version of this asset. If it even exists since it's relatively old. The only versions we have here are for daz 4.5 and below (and of course it says that it's made for another version, if I try to "install" it), so.. to be fair, I also don't expect this request to be fullfilled anytime soon since the price for it is really, really high and unless someone have it already, this will probably stay here for a long time.

But I'm gonna try it anyway! My offer is 1k for it!

3a8082e126