Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
it is becoming essential for me to use this as the newer content exceeds my hardware's ability more and more, so thanks for continued development, looking forward to the update
I did not know it disappeared from the DIM. Can you let me know if you still have the issue?
Well yes. I think you'd preferably optimize from frame 0, and then all the other frames should follow.
No it is not the case any longer, you can place the new maps in any content folder you want, even a content folder you would create yourself.
Thanks!
Been looking forward to this update.
I don't undertand? The update is not live for you? It's been released for a while now, and I updated it to version 1.1 using Smart Content without any issue. What do you use for the udpate? Smart Content? DIM? Please just let me know, because if there is a DIM issue not showing the update, I'll have to contact Daz for that. But my own version of my product being Smart Content, it does not appear any longer in the DIM so I cannot check if an update appears or not.
The update did not show as an update in DIM for me so I did a mnual update, HOWEVER, checking the details in DIM shows the package date as Tuesday, 12 March 2019 3:53:16 AM (2019-03-11T16:53:16Z), so I guess it sneaked in when I wasn't looking.
Fine, I'll wait and see, if people have issues with finding the DIM update. In this case, I'll act.
Though Scene Optimizer has helped me immensely since I have bought it, recently it is acting strange for me.
1. After reducing texture maps, SO doesn't seem to recognize it has after the fact. When opening up SO again on the same scene, it still shows various maps are 4096x4096. The Surface panel certainly shows the low res maps are there, so I don't understand why this is. This happens in different scenes, on 4.11 and 4.10. Also with older and new nVidia drivers.
2. Iray is giving me completely different texture allocation with the same scene. After reduction, sometimes it will show 200mb textures all the way up to 4 GB textures. The total seems different on 4.11 and 4.10, sometimes the differences are the same app version but I just opened it up after shutting Daz down with the task manager. Also Iray seems to be rendering the first scene with GPUs (I have 4 1080tis), but then drops down to CPU for the second frame, or in the case of 4.10, just crashes Daz. This might have nothing to do with SO, but it might be indicative of something else happening.
3. What is the easiest way of remembering your models' subdivision settings outside of Notepad or pen and paper, after doing mesh reduction? It would be nice to save the subdivision sets like we can the textures.
Did you save the scene after running Scene Optimizer, so a version of the scene is saved with the reduced textures. If not, the originally saved scene will load again with the original textures.
Hi barbult,
Yes, I did! It's weird because this was never a problem before. In fact, I even reduced the textures further, so that they are effectively x32 and still, when the scene is re-opened they are still showing at 4096x4096.
Are they JPEG or PNG files? Scene Optimizer has some issues with some PNG files.
I bet they are png, though I'm in the middle of a render so I can't check. The reason I think they are png is because the problems started when I loaded 8 Genesis 8 characthers fully clothed into my scene.
ok, after looking at the image files, most of them are jpg. The plot thickens!
Hi @barbult it looks like you are on to something. More thorough investigation shows that the files are all png that aren't optimizing.
There are a couple checkboxes in the interface to force it to process PNG files. I check both if I want to be sure they get processed. There is some complicated complexity about PNG files that I don't remember the details of. I think it is documented in the user manual. I know V3Digitimes worked for a long time to get PNG files optimized, but there were conflicting issues that couldn't all be accomodated, so she opted for the safest way, I think.
Hi @barbult,
Yes! I've started to notice this too. I haven't quite got the hang of it yet. For me, the reduced png files seem to get made, but not load up. I forced the issue as you described, but then I can't quite tell when to save or not. It's explained in the manual but I read it 3 times and I was still confused! :-D Thanks for the help on this! I think I've almost got it.
Hello,
thanks for your intervention Barb!
Indeed, the png image maps with "real" transparency are not well processed during the size reduction stage, the transparent part becoming black after size reduction. This is why, since now a lot of eyebrows are made with such files (png with transparency on diffuse overlay), the program is now made (updated) so that the png image maps are not treated by default. You must specifically ask for it by checking the box begining with "also reduce LIE maps.....".
I think that you must also check the second checkbox just bellow, it is hard to explain in detail, but it was made to prevent people who have created black png images to be reloaded during another optimizer session when it is unchecked ... (it would be very long to explain in detail). So in brief, check both options, and normally the png should be treated properly. If it does not work, let me know.
I'll have a look if I made it clear in the documentation, I think I updated it but I made so many modifications, then modified the modifications, then modified the mofications of the modifications, on the specific case of the png files that I'm not sure the documentation is clear. Anyway, if I see this is not clear, I will re-update the documentation!
As soon as the reduced size png files are in the right slots you can save your scene, it will reload with this file. You can even set your asset as a new scene subset, it will have the reduced png files on it!
Hi @V3Digitimes!
Thank you for the clarification. I'm a big fan of your stuff by the way! I'm doing a scene with 40+ characters so Scene Optimizer and Iray Converter have been constant go-tos through the whole process.
I got everything to work with the "also Reduce LIE maps". The only stickler is that somewhere in the process Scene Optimizer put some files in the AppData folder, and I've had a hard time locating everything. It seems it mostly did this with "tattoo" and decal L.I.E. type-stuff. But, I think I read about this in the manual too, so at some point I must review.
Personally, I'd rather have the black spots appear as a default, rather than the other way around, and a checkbox that gives you the option of opting out with an explanation as to what's happening... since I use SO mostly for scene placement and figuring out which maps get high or low maps based on the animation. But, this way is fine, too.
There is no way I could do my current project without this utility. Thanks for all the hard work on it!
Hi,
sorry I'm in a hurry I have an appointment right now, so I go to the essential : I'm glad to see most of your issues are solved. What you have to know is that all the appdata stuff is related to Daz Studio itself, not to my Optimizer. It is where the baked maps of LIE are placed by Daz Studio. This is why my product also provide additional script (store/restore). If I remember well, if you use the "Store" script, the LIE maps will be baked in runtime. (I don't remember if you have to make store only or store and restore, I almost never use LIE). Normally this is in the documentation. But this LIE case is treated by all the scripts included in the product. (One IMPORTANT NOTE for scenes with LIE, is that the scenes must be saved before launching the scripts "V3DSO 01 Store Scene Texture Map State" or "V3DSO 02 Scene Optimizer" otherwise, the LIE baked maps will be ignored (ignored when storing maps paths and ignored during the maps size reduction step).)
Sorry I really have to go, let me know if my answer did not help you and you still need help.
I'm having an odd and very specific problem with this script.
If I have the snake hair from Sixus1's "Medusa for V4" over at Renderosity in the scene, it causes DS to crash on closing the script window - even if nothing has been done within the window, and even if it's the only model in the scene.
This applies regardless of whether the hair is using its original Poser materials, an Iray converted version of those materials, or generic textureless Iray materials. I've also tried converting from the original imported rigging to both TriAx and General weights, and saving those out specifically as a Daz format figure asset; it still crashes.
That leaves very few things left that I can actually convincingly pin it on; the model has got some reasonably complex control links to make controlling the very large number of bones involved (about 600, if I recall), but I can't see why this optimizer script should be interacting with those. (And for the sake of completeness, I've tested other Poser models with pose preset sliders - they don't crash the script).
Obviously, as I know what prop is causing the issue, I can theoretically work around it, but it's a pain to have to remember to save the hair pose, remove it from the scene, optimise, then reload the model*. (And if I forget to do that before opening the script, I don't know of anything I can do to then prevent a crash or save my work).
* Although it is an old V4 asset, it still looks great on newer models and has such a wonderful sense of movement, so I don't really want to have to swap to another gorgon hair prop, particularly as I've established this particular character's look.
~~~~~
As far as more technical information (Yes, my system spec is fairly poor, but that's part of why the scene optimiser script is so useful to me)
Core i7 4790
GTX 1050 Ti 4GB, currently on the latest 441.12 driver. As far as older drivers, I'm also fairly sure I've seen this issue on the 398.36, 417.71 and 419.35 drivers.
Windows 8.1 64-bit
16 GB RAM
Daz Studio 4.12.0.86 (although I also experienced the same crash in DS 4.10, even if it's taken me time to work out exactly what the culprit is).
The main note I get on a crash is:
DAZStudio.exe caused ACCESS_VIOLATION in module "C:\Program Files\DAZ 3D\DAZStudio4\QtScript4.dll" at 0033:00000000E0A1E1BC, QScriptEngine::signalHandlerException()+18380 byte(s)
These are the final lines of the log file - other than starting DS, all that has been done is importing the original Poser version of the model, immediately opening the Optimiser script, and then closing the window without making any changes (although unfortunately there's nothing here that's been useful to me).
2019-11-08 02:19:33.040 WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(660): sync completed successfully, 1 items succeeded, 0 items failed.
2019-11-08 02:19:33.040 Metadata update succeeded.
2019-11-08 02:19:33.314 WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(178): peer performed orderly shutdown errno=0
2019-11-08 02:19:45.894 Importing File...
2019-11-08 02:19:45.894 Importing MedusaSnakes.cr2 ...
2019-11-08 02:19:45.899 Warning: No version number specified on line 5 in ../Renderosity/Runtime/Libraries/Character/Medusa/MedusaSnakes.cr2
2019-11-08 02:19:45.903 Reading MedusaSnakes.obj
2019-11-08 02:20:08.407 PZ3Importer: Removing face group default no associated node.
2019-11-08 02:20:08.784 File imported in: 0.22 sec (22890.3 ms)
2019-11-08 02:20:11.255 Loaded image Medusa_ScalpC1.jpg
2019-11-08 02:20:11.285 Loaded image Medusa_ScalpT1.jpg
2019-11-08 02:20:11.315 Imported file: ..\Renderosity\Runtime\Libraries\Character\Medusa\MedusaSnakes.cr2
2019-11-08 02:20:11.345 Building Scene...
2019-11-08 02:20:11.401 File loaded in 0 min 25.5 sec.
2019-11-08 02:20:11.401 Loaded file: MedusaSnakes.cr2
2019-11-08 02:20:22.552 WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(178): recv failed errno=10054
Hi,
this is indeed very strange, first time I hear about something like that. Here is a few question so that I can investigate:
1. Does it change something if you save your scene before you launch the script? This way if something need to be written as new data for your poser object, they will properly exist when you launch the script. If you test this, the best is maybe even to save the scene, relaunch DS (just to make sure, as a test).
2. Does it ALSO happen if you "uncheck" the medusa hair from the list of processed elements before doing anything else (before closing the script)? Because in the second case, the solution might just be to remember to uncheck it from the list in the script until a more definitive solution is found.
The error message in the log file, something in the script seems to generate 'A signal which is emitted when a script function connected to a signal causes an exception'. If we don't find additional clues with my questions, I'll ask Daz Support if they have an idea on their side.
Answering your specific questions:
1) It happens even if I've saved - given I wasn't sure of the cause of the script's crashes for some time, I tried to develop the habit of saving first, but it does crash both after saving and after reloading the scene. It also happens with the versions I've resaved with DS formats and weight mapping, so I don't think it's anything to do with it being a Poser asset.
EDIT: I forgot to mention that I have tested other Poser assets, with seemingly no problem.
2) It does still crash if I uncheck the hair from the processed elements.
And, for the sake of completeness, I'll add that it does also crash if the hair is processed; I normally wouldn't, as it doesn't use a huge amount of texture memory and it's often fairly close to the camera, but I've now specifically checked that. (And it's pretty high mesh resolution anyway, at about 135k faces so I don't add any SubD modifiers for it to show up on that list). While not ideal, being able to process the hair, avoid the crash, and then reload a materials preset to put back the full resolution textures would have been a more practical work around.
~~~~~
While I'm at the experimentation:
- a version exported to OBJ and then reimported did not crash the script. It's therefore presumably not anything inherent to the mesh geometry. (Which was always unlikely, but the more things that can be ruled out the better).
- a renamed version (both the node name and the display name, via scene identification) of the prop however does crash the script. The name was just "MedusaSnakes", which shouldn't have caused any problems, but for the sake of testing, I changed it in case somehow that name was causing some one-in-a-billion bug with memory handling or the like.
- However, probably the most relevant thing is that I can take steps to have the model also crash Fit Control. I normally only parent the hair to the head of the model, as fitting it would completely mess up the shape (auto-fit actually freezes, but if I fit it using scene identification, some of the snakes start to take the shape of the shoulder morphs); this means it doesn't normally show up on the check-list of clothing to be processed, but if I do fit it to the figure, then the same symptoms occur - it crashes when the script window is closed and control is passed back to the main Studio window, even if it's not processed.
With that in mind, I'd suggest that the error is either within DazScript itself or within some code library you've both used. (I'm rather hoping it's the latter, as I'm not holding out massive hope of Daz rushing to fix bugs in their scripting language for the benefit of an old asset from an entirely different store, particularly if I can't quite nail down why it's happening).
Interestingly, loading the Shape Rigger Plus script and processing rigging for morphs (on a weightmapped version of the hair) does not crash Daz. In this case, the hair itself does not show up on any checklist, even if some of its morphs do.
I'm assuming that it seems it's not a problem you can deal with, but I thought I'd check before I tried to take it up with Daz support myself.
(Although I don't suspect I'll have much success with that. Complaining that an old model from another store crashes DS probably isn't going to get given much attention).
Maybe for the next update there could be an option to select all maps bigger than x for division. Saves unchecking 1000 maps which are small enough lol.
Oh, and a column for Normal maps so that we can see which asset contains them. So that e.g. one can remove Normal maps from assets but not figures.
Smart! I like that!
Well for this, simply remove the normal maps from all assets (and not figures). The script does not care if a normal map is there or not, so this is not an issue if you try to remove a normal map of an asset which does not have normal maps, this is why you can uncheck only the figures if you want too. Did I well understood your issue?
Ouch, forgot to add: I had a look at this, but I was not able to see what could cause a crash with your product. The other issue is that I don't have the product which causes issues to test it myself, but reading your log file lines, I had not enough clues to see what could go wrong.
I don't want to overdo things, as I know you don't like complicated stuff
My initial thought was a Normals column which shows what contains normal maps. If I attach a screenshot from SimTenero's Iray Memory Assistant, you will see what I mean (the first 2 items are the figures). One could simply just remove normal maps from all assets but not figures. But then clothing has normal maps. So to make things easier for you, a column and the user can decide what to check and uncheck 
Ah OK, yes outfits can have normal maps! I forgot them! I understand the interest now. Yes this is really not complicated to add such a column, I immediately add it to the request list for the next update. Thanks for the answer, I had not seen your issue with the right angle, now it's clear!
i've been using scene optimizer a lot these past few weeks, and i can't tell you how glad i am that you created this wonderful tool. it's miraculous. scenes that my GTX 1080 were choking on purr along happily instead of defaulting to my CPU.
i'm optimizing a new environment, and i'm wondering if you'd mind giving me a few tips on map selection in the tool and the way they impact scene definition and render times. in kind of cost-benefit analysis way. i'm probably only using scene optimizer about half as well as i could be using it.
my sense of things is as follows. but my take is basically semi-informed guesswork, and i'd appreciate a more knowledgeable point of view. because i'm probably wrong about some stuff. :)
- figure subD has the strongest impact on definition and GPU load.
- displacement maps have an impact on definition and GPU load equivalent to upping a figure's subD level, and if set above 1 have the greatest impact on scene load of any of the other surface maps. (i'm not sure exactly how that maths out, though. if i apply a displacement map to a character's hands at 2.0, and that character's subD level is already set at 3, does that mean that details on the hand are rendering at subD 5?)
- normal maps are next highest in terms of definition and GPU load because they also affect the figure's geometry.
- bump maps have less impact on both definition and GPU load, because they're basically faking vertex and polygon depth and the way light interacts with the surface.
- diffuse channel maps' impact depends mostly on their size. (i don't know if there's any multiplication of scene load involved if the same map is repeated a number of times, as it would be when it's serving all the leaves of a tree, or tiled x16 on a clothing mat zone. that's something that would be good to know.) scaling a diffuse map to 50 percent probably cuts its scene load weight in half, too.
and i have absolutely no idea how much instancing reduces the scene load. i have the sense that they do lighten the load considerably, but they do have a cumulative impact.
i'm also a little fuzzy on which maps would be the best choices to keep if i want to keep some sense of crisp definition at mid or long range? getting treebark edges to catch light, for instance. i've been removing the displacement maps and bump maps and keeping the normals. should i be keeping the bump maps instead?
anyway...if you have the time and inclination to educate me a little along these lines, i'd really appreciate it.
:)
j