So I could theoretically eat nothing other then ramen noodles for three months and get one of them dual-socket systems with win7 (I want a computer not a cell phone interface, lol), and hypothetically daz studio would use both processors? That is tempting, although I'm not sure I would survive three months of ramen noodles,
I have a big problem with this release. DAZ no longer finds my Titan X as an iRay render device?
Basically I can't use iray at all .. what the hell do I do now?
According to the log file .. the end part says ...
2017-01-09 05:34:32.740 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating geometry.
2017-01-09 05:34:32.740 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Using OptiX Prime ray tracing (3.9.1).
2017-01-09 05:34:32.740 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Importing geometry.
2017-01-09 05:34:32.744 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Geometry import (1 object with 2 triangles, 1 instance yielding 2 triangles) took 0.000133
2017-01-09 05:34:32.744 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating materials.
2017-01-09 05:34:32.744 Iray INFO - module:category(MATCNV:RENDER): 1.0 MATCNV rend info : found 1 textures, 0 lambdas (0 unique)
2017-01-09 05:34:32.744 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Emitter geometry import (1 light source with 2 triangles, 1 instance) took 0.00s
2017-01-09 05:34:32.748 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating environment.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating lens.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating lights.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating object flags.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating caustic portals.
2017-01-09 05:34:32.759 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating decals.
2017-01-09 05:34:32.760 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Allocating 1 layer frame buffer
2017-01-09 05:34:32.769 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Using interactive scheduling, architectural sampler unavailable, caustic sampler disabled
2017-01-09 05:34:32.769 WARNING: dzneuraymgr.cpp(307): Iray ERROR - module:category(IRAY:RENDER): 1.0 IRAY rend error: Cannot render: found no usable devices.
2017-01-09 05:34:32.773 Iray Render error: Invalid parameters (NULL pointer).
Would appreciate any help please .. cos I NEED this to work.
I think there is a minimum video card driver version that goes hand in hand with this version of Studio. I had a similar problem with a GTX960 that worked fine before this beta/release. It took a bit to find a driver version that worked with the GTX960 an older GT730 card and the newer Studio. What driver version are you using with the Titan?
Is that driver version limit only on GPU rendering? Can we still do CPU rendering no matter what? I don't have a card that can handle the v372+ drivers, and I might not be able to get one for a while.
Is that driver version limit only on GPU rendering? Can we still do CPU rendering no matter what? I don't have a card that can handle the v372+ drivers, and I might not be able to get one for a while.
Don't know for sure with build 166, the former 153 build worked with CPU Iray with older drivers. Good question, I hesitate to say 166 will be fine with CPU Iray rendering with older video drivers.
Not to say I understand the PITA of updating drivers with older cards. It's a bit of a pain finding one that dose not make videos stutter or crash with older affordable tech. Advice, make a backup of the old Daz Studio install zip 'Before' you attempt to download the new one. You want to save the zip and the dsx files, the file name will be something like the folowing.
IM00012000-02_DAZStudio49PublicBuildWin64bit.dsx
IM00012000-02_DAZStudio49PublicBuildWin64bit.zip
IM00013176-02_DAZStudio48Win64bit.dsx
IM00013176-02_DAZStudio48Win64bit.zip
P.S. Thank you namffuak , I could not remember the driver version number, that was to many cups of coffee and pages ago.
...found a small bug when saving Scenes/Scene Subsets. Instead of defaulting ot the DAZ3D/DAZ 4/Scenes or Scene Subsets folder like it normally does (the other Beta releases had no issue with this) the .166 Beta is selecting whatever folder was last opened on the system.
Not major, but it is a bother to keep having to manually navigate to the proper folder for saving.
4.9.3.166 is now a general release version, though ti should still be avaialble as a beta too - check that you have Public Builds checked in Download Filters in Install manager, assuming you have bought the beta from the store.
...found a small bug when saving Scenes/Scene Subsets. Instead of defaulting ot the DAZ3D/DAZ 4/Scenes or Scene Subsets folder like it normally does (the other Beta releases had no issue with this) the .166 Beta is selecting whatever folder was last opened on the system.
Not major, but it is a bother to keep having to manually navigate to the proper folder for saving.
It should remember the last path used - and it seemed to be tracking thems eparately when I saved a preset yesterday.
I apologize if this has been addressed already but after updating to version 4.9.3.166 my renders appear grainier than the previous version (it was 4.9.2.xx). It seems like I saw something about this somewhere but can't seem to able to find it now. Is this a known issue? What setting(s) should I change to correct this?
Is the volume brick no longer supported in 4.9.3.166?
I've been having issues with 4.9.3.166 crashing (completely and causing a reboot) when rendering with 3DL. This is happening on render slaves I have setup, so I'm not actually there when it happens. I found some interesting warnings in the logs about the volume brick, so I made a simple scene that only has a cube in it with the following shader applied:
Loading this scene in DS yields the following in the log:
2017-01-31 15:26:46.634 *** Scene Cleared ***
2017-01-31 15:26:46.634 File loaded in 0 min 0.0 sec.
2017-01-31 15:26:46.634 Loaded file: algovincian-volume.duf
2017-01-31 15:26:46.775 Compiled C:/Users/algo-03/AppData/Roaming/DAZ 3D/Studio4/temp/shaders/brickyard/{1bca4a09-085e-42eb-ae59-6bdc08c648a1}/shader_Surface.sdl...
2017-01-31 15:26:46.806 Compiled C:/Users/algo-03/AppData/Roaming/DAZ 3D/Studio4/temp/shaders/brickyard/{1bca4a09-085e-42eb-ae59-6bdc08c648a1}/shader_Volume.sdl...
2017-01-31 15:26:46.806 stdin: in function shader_Volume
stdin:113: WARNING: initializing point 'IObj' with a vector
stdin:114: WARNING: initializing point 'origin' with a vector
stdin:116: WARNING: type mismatch for argument number 1 of 'normalize': 'normal' expected instead of 'point' (near 'IObj')
stdin:121: WARNING: type mismatch for argument number 1 of 'length': 'vector' expected instead of 'point' (near 'IObj')
stdin: in function elr_7b2d749a_c357_4cfc_916a_c79ab45ca638_token_7
stdin:86: WARNING: variable 'elr_shadow_density_b3_t0' should be declared as 'extern'
stdin: in function shader_Volume
stdin:153: WARNING: argument number 2 of 'elr_7b2d749a_c357_4cfc_916a_c79ab45ca638_token_7' function should be in '"current"' coordinate system (not in '"shader"' coordinate system according to other 'input' arguments) (near 'ShaderRayMarchPoint')
stdin:153: WARNING: argument number 3 of 'elr_7b2d749a_c357_4cfc_916a_c79ab45ca638_token_7' function should be in '"current"' coordinate system (not in '"shader"' coordinate system according to other 'input' arguments) (near 'vtransform')
Also, I took the time to render a scene with this shader used in it on another box running 4.9.3.166. Stuck around to see what happens and ended up with a crash. Here's the screencaps of the message:
I was not rendering OGL at the time - just a standard 3DL render to a new window.
One more thing, I've been getting these new messages when rendering in 3DL under 4.9.3.166 and have yet to figure out any rhyme/reason:
Any information anybody could provide would be greatly appreciated - thanks!
- Greg
ETA: Sorry - meant to add this in the release thread. If it can be moved, please do so.
I'm having major problems with this release. For starters, saving poses doesn't work, I have to save as a parameter and check the appropriate boxes (and even that doesn't save the pose as well as using pose preset). Then tonight, it crashed twice upon attempting to save a new scene (at 99%), costing me a lot of work. Unless someone knows what could be going on, I'm not touching Studio again until the next update.
I just updated to 4.9.3.166 RC5 and I cant seem to render anything. It renders a white picture lol w/o figures or anything. Anyone else seen this and know what can be done? Many thanks in advance.
HELP! DAZ is crashing when I try to render anything. It started with only half rendering, now it crashes. Started doing this about a few weeks ago, up until then working fine. I have lost hours of work. Any help would be appreciated. I'm using 4.9.3.166 Pro 64 Bit Version. Windows 8.1, 64 bit i7. GForce 965M. 32 GB Ram. Thank you.
Hmm, this all dont sound good. Me thinks I will leave this one alone
This is the current release build, and is geenrally working. Though you can always test with the beta to make sure you don't lose the version you currently use if you are one of the unlucky ones for whom it doesn't work well.
I am in the middle of a project (quite a complex one) now somewwhere along the line Daz Studio started saving the geometry files from the scene I have been building directly into the scene .duf file.
Previously it exported geometry files to the auto_adapted folder as a .dsf file with a reference to that directory in the saved scene or scene subset .duf file (making that file a lot smaller and less complex)
So what has happened? I have searched through the preferences, looked online and much more to see if it is possibly something I have enabled...or has this been changed so all geometry is saved in the .duf
file in new versions of Daz Studio.
I really need it to go back the auto_adapted setting, I cant work like this, I have several scenes and they are getting too large now they are storing the geometry in each .duf scene file.
Daz 4.9.3.166 even saves a basic Daz created sphere as an obj embedded in the .duf scene file.
Anything new I create or import (.obj) gets saved in the .duf scene in an embedded form ...it no longer writes it out to the auro_adapted folder
I checked an earlier version of 4.9...this does the same, it happened somehwere when I did an update...i dont use the geometry editor tool.
Maybe you could very kindly do a quick test...take 4.9..create a sphere primitive and save it as a scene subset, open that with a text file and see if the geometry
is embedded..and/or if its sent to auto_adapted folder .
That way I would know for sure if its a Daz upgrade change...or something has happened...i cant think what tho..
Yep...I thought that might be the case, somewhere this happened, its a big issue because it means if you want to set up several scenes, then the size gets blown out because each scene has embedded obj in it.
Where do I report it?
Also is it possible to download an older version of DS with Iray that does not have this problem, are there any links?...not sure when this happened?
Hey Richard...thanks yeah...after more tests I found out something.
In older versions (I have one on a back up drive...thankfully) it does not matter if you create a primitive in DS
If you save it as a subset, it will embed the obj file into the scene...so older versions and newer versions of 4.9 do this.
BUT if you created a model in another app save it as an .obj and import it into DS then save it as a scene or scene subset
then the latest version of DS will embed the models data into the scene file...whereas the earlier version of 4.9 writes it to auto adapted
so I have a work around, its gonna take a bit longer but at least I can finish my work...annoying but happy that I can at least deal with this problem.
I am amazed that more people are not complaining about this as it makes creating multiple scenes impractical.
In reality when you first save a scene or subset daz studio should have the option of letting you create a directory where you woyld like to store
obj type data...thats even better than the auto_adapted thing which usually requires a good amount of cleaning up to get the directories working cleanly
but still even thats better than what is happening in the latest DS 4.9 build.
Hey Richard...thanks yeah...after more tests I found out something.
In older versions (I have one on a back up drive...thankfully) it does not matter if you create a primitive in DS
If you save it as a subset, it will embed the obj file into the scene...so older versions and newer versions of 4.9 do this.
BUT if you created a model in another app save it as an .obj and import it into DS then save it as a scene or scene subset
then the latest version of DS will embed the models data into the scene file...whereas the earlier version of 4.9 writes it to auto adapted
so I have a work around, its gonna take a bit longer but at least I can finish my work...annoying but happy that I can at least deal with this problem.
I am amazed that more people are not complaining about this as it makes creating multiple scenes impractical.
In reality when you first save a scene or subset daz studio should have the option of letting you create a directory where you woyld like to store
obj type data...thats even better than the auto_adapted thing which usually requires a good amount of cleaning up to get the directories working cleanly
but still even thats better than what is happening in the latest DS 4.9 build.
Cheers
Wouldn't saving your modeled item(s) as Figure or Prop asset and then including those in your scene avoid this problem?
Hi...its possible that could avoid the problem...maybe.
But daz Studio has changed its importing and saving scene files somewhere in the 4.9 builds...and another point is that Daz Studio probably should have an option where to place geometry data so the scene file can reference to it when you dave it.
For example with auto_adapted (saving a large scene) you have to delete the ato_adapted reference, delete the legacy obj info refence in both the .dsf and .duf files and add in the
proper references to the desired directory...I have never mentioned or complained about this, because I have a system that gets around this, but it is a feature thats missing in DS.
Plus saving a large scene with nearly 3 million polys...and many different props and instances...this type of workaround can take a lot of time...like days...many days.
I enclosed a render of part of the scene so you can see what I mean.
Bottom line I am happy that I have a previous version of DS 4.9 that does not have this problem so I can finish my work.
Expand Edit under Action, right-click on e.g. Undo. See screenshot.
Thank you. There are no shortcuts listed there. I've added a few and applied. Those are now working. So somehow, when I updated to the latest beta, I managed to wipe out all the shortcuts! I wonder what I did to do that. It must have been something I did, or everyone would be in here complaining...! Now all I have to do is find all of them and set them back to what they should be! Fun times.
Thanks again for your help. I was really frustrated they weren't working.
ETA: I discovered the "Default Keyboard Shortcut" menu item after right-clicking to set the shortcut. That helped a lot. Though I still needed to view the same in the 4.9 release, to see which shortcuts were in use. When I tried setting the default on one action, it said that shortcut was already in use... But all in all, it's going much faster now.
Import... > Actions > OK > Default Advanced.dsx > Open
Hey Richard...thanks yeah...after more tests I found out something.
In older versions (I have one on a back up drive...thankfully) it does not matter if you create a primitive in DS
If you save it as a subset, it will embed the obj file into the scene...so older versions and newer versions of 4.9 do this.
BUT if you created a model in another app save it as an .obj and import it into DS then save it as a scene or scene subset
then the latest version of DS will embed the models data into the scene file...whereas the earlier version of 4.9 writes it to auto adapted
so I have a work around, its gonna take a bit longer but at least I can finish my work...annoying but happy that I can at least deal with this problem.
I am amazed that more people are not complaining about this as it makes creating multiple scenes impractical.
In reality when you first save a scene or subset daz studio should have the option of letting you create a directory where you woyld like to store
obj type data...thats even better than the auto_adapted thing which usually requires a good amount of cleaning up to get the directories working cleanly
but still even thats better than what is happening in the latest DS 4.9 build.
Cheers
Yes, it would... and that is the point behind fixing what has otherwise been a bug in builds prior to the 4.9.3.x build that addressed it.
Comments
So I could theoretically eat nothing other then ramen noodles for three months and get one of them dual-socket systems with win7 (I want a computer not a cell phone interface, lol), and hypothetically daz studio would use both processors? That is tempting, although I'm not sure I would survive three months of ramen noodles,
there isn't much to me, lol.
I have a big problem with this release. DAZ no longer finds my Titan X as an iRay render device?
Basically I can't use iray at all .. what the hell do I do now?
According to the log file .. the end part says ...
2017-01-09 05:34:32.740 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating geometry.
2017-01-09 05:34:32.740 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Using OptiX Prime ray tracing (3.9.1).
2017-01-09 05:34:32.740 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Importing geometry.
2017-01-09 05:34:32.744 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Geometry import (1 object with 2 triangles, 1 instance yielding 2 triangles) took 0.000133
2017-01-09 05:34:32.744 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating materials.
2017-01-09 05:34:32.744 Iray INFO - module:category(MATCNV:RENDER): 1.0 MATCNV rend info : found 1 textures, 0 lambdas (0 unique)
2017-01-09 05:34:32.744 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Emitter geometry import (1 light source with 2 triangles, 1 instance) took 0.00s
2017-01-09 05:34:32.748 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating environment.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating lens.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating lights.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating object flags.
2017-01-09 05:34:32.755 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating caustic portals.
2017-01-09 05:34:32.759 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Updating decals.
2017-01-09 05:34:32.760 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Allocating 1 layer frame buffer
2017-01-09 05:34:32.769 Iray INFO - module:category(IRAY:RENDER): 1.0 IRAY rend info : Using interactive scheduling, architectural sampler unavailable, caustic sampler disabled
2017-01-09 05:34:32.769 WARNING: dzneuraymgr.cpp(307): Iray ERROR - module:category(IRAY:RENDER): 1.0 IRAY rend error: Cannot render: found no usable devices.
2017-01-09 05:34:32.773 Iray Render error: Invalid parameters (NULL pointer).
Would appreciate any help please .. cos I NEED this to work.
I think there is a minimum video card driver version that goes hand in hand with this version of Studio. I had a similar problem with a GTX960 that worked fine before this beta/release. It took a bit to find a driver version that worked with the GTX960 an older GT730 card and the newer Studio. What driver version are you using with the Titan?
The minimum Nvidia driver version is now 372.xx; anything older won't work with this Iray release.
Is that driver version limit only on GPU rendering? Can we still do CPU rendering no matter what? I don't have a card that can handle the v372+ drivers, and I might not be able to get one for a while.
Don't know for sure with build 166, the former 153 build worked with CPU Iray with older drivers. Good question, I hesitate to say 166 will be fine with CPU Iray rendering with older video drivers.
Not to say I understand the PITA of updating drivers with older cards. It's a bit of a pain finding one that dose not make videos stutter or crash with older affordable tech. Advice, make a backup of the old Daz Studio install zip 'Before' you attempt to download the new one. You want to save the zip and the dsx files, the file name will be something like the folowing.
IM00012000-02_DAZStudio49PublicBuildWin64bit.dsx
IM00012000-02_DAZStudio49PublicBuildWin64bit.zip
IM00013176-02_DAZStudio48Win64bit.dsx
IM00013176-02_DAZStudio48Win64bit.zip
P.S. Thank you namffuak
, I could not remember the driver version number, that was to many cups of coffee and pages ago.
Yep that was it .. I needed to just update the NVIDIA software driver. Iray is now working fine.
...found a small bug when saving Scenes/Scene Subsets. Instead of defaulting ot the DAZ3D/DAZ 4/Scenes or Scene Subsets folder like it normally does (the other Beta releases had no issue with this) the .166 Beta is selecting whatever folder was last opened on the system.
Not major, but it is a bother to keep having to manually navigate to the proper folder for saving.
WHERE IS IT?+
4.9.3.166 is now a general release version, though ti should still be avaialble as a beta too - check that you have Public Builds checked in Download Filters in Install manager, assuming you have bought the beta from the store.
It should remember the last path used - and it seemed to be tracking thems eparately when I saved a preset yesterday.
I apologize if this has been addressed already but after updating to version 4.9.3.166 my renders appear grainier than the previous version (it was 4.9.2.xx). It seems like I saw something about this somewhere but can't seem to able to find it now. Is this a known issue? What setting(s) should I change to correct this?
Thanks.
Is the volume brick no longer supported in 4.9.3.166?
I've been having issues with 4.9.3.166 crashing (completely and causing a reboot) when rendering with 3DL. This is happening on render slaves I have setup, so I'm not actually there when it happens. I found some interesting warnings in the logs about the volume brick, so I made a simple scene that only has a cube in it with the following shader applied:
Loading this scene in DS yields the following in the log:
2017-01-31 15:26:46.634 *** Scene Cleared ***
2017-01-31 15:26:46.634 File loaded in 0 min 0.0 sec.
2017-01-31 15:26:46.634 Loaded file: algovincian-volume.duf
2017-01-31 15:26:46.775 Compiled C:/Users/algo-03/AppData/Roaming/DAZ 3D/Studio4/temp/shaders/brickyard/{1bca4a09-085e-42eb-ae59-6bdc08c648a1}/shader_Surface.sdl...
2017-01-31 15:26:46.806 Compiled C:/Users/algo-03/AppData/Roaming/DAZ 3D/Studio4/temp/shaders/brickyard/{1bca4a09-085e-42eb-ae59-6bdc08c648a1}/shader_Volume.sdl...
2017-01-31 15:26:46.806 stdin: in function shader_Volume
stdin:113: WARNING: initializing point 'IObj' with a vector
stdin:114: WARNING: initializing point 'origin' with a vector
stdin:116: WARNING: type mismatch for argument number 1 of 'normalize': 'normal' expected instead of 'point' (near 'IObj')
stdin:121: WARNING: type mismatch for argument number 1 of 'length': 'vector' expected instead of 'point' (near 'IObj')
stdin: in function elr_7b2d749a_c357_4cfc_916a_c79ab45ca638_token_7
stdin:86: WARNING: variable 'elr_shadow_density_b3_t0' should be declared as 'extern'
stdin: in function shader_Volume
stdin:153: WARNING: argument number 2 of 'elr_7b2d749a_c357_4cfc_916a_c79ab45ca638_token_7' function should be in '"current"' coordinate system (not in '"shader"' coordinate system according to other 'input' arguments) (near 'ShaderRayMarchPoint')
stdin:153: WARNING: argument number 3 of 'elr_7b2d749a_c357_4cfc_916a_c79ab45ca638_token_7' function should be in '"current"' coordinate system (not in '"shader"' coordinate system according to other 'input' arguments) (near 'vtransform')
Also, I took the time to render a scene with this shader used in it on another box running 4.9.3.166. Stuck around to see what happens and ended up with a crash. Here's the screencaps of the message:
I was not rendering OGL at the time - just a standard 3DL render to a new window.
One more thing, I've been getting these new messages when rendering in 3DL under 4.9.3.166 and have yet to figure out any rhyme/reason:
Any information anybody could provide would be greatly appreciated - thanks!
- Greg
ETA: Sorry - meant to add this in the release thread. If it can be moved, please do so.
I'm having major problems with this release. For starters, saving poses doesn't work, I have to save as a parameter and check the appropriate boxes (and even that doesn't save the pose as well as using pose preset). Then tonight, it crashed twice upon attempting to save a new scene (at 99%), costing me a lot of work. Unless someone knows what could be going on, I'm not touching Studio again until the next update.
I just updated to 4.9.3.166 RC5 and I cant seem to render anything. It renders a white picture lol w/o figures or anything. Anyone else seen this and know what can be done? Many thanks in advance.
Do you see the items in the viewport before rendering?
HELP! DAZ is crashing when I try to render anything. It started with only half rendering, now it crashes. Started doing this about a few weeks ago, up until then working fine. I have lost hours of work. Any help would be appreciated. I'm using 4.9.3.166 Pro 64 Bit Version. Windows 8.1, 64 bit i7. GForce 965M. 32 GB Ram. Thank you.
Try unchecking OptiX Priem in the Advanced tab of Render Settings - that appears to be the precise crash element.
Hmm, this all dont sound good. Me thinks I will leave this one alone
This is the current release build, and is geenrally working. Though you can always test with the beta to make sure you don't lose the version you currently use if you are one of the unlucky ones for whom it doesn't work well.
I have a question, its pretty urgent
I am in the middle of a project (quite a complex one) now somewwhere along the line Daz Studio started saving the geometry files from the scene I have been building directly into the scene .duf file.
Previously it exported geometry files to the auto_adapted folder as a .dsf file with a reference to that directory in the saved scene or scene subset .duf file (making that file a lot smaller and less complex)
So what has happened? I have searched through the preferences, looked online and much more to see if it is possibly something I have enabled...or has this been changed so all geometry is saved in the .duf
file in new versions of Daz Studio.
I really need it to go back the auto_adapted setting, I cant work like this, I have several scenes and they are getting too large now they are storing the geometry in each .duf scene file.
Can somebody please explain what has happened
Thanks
Have you customised the geometry with the Geometry Editor tool in any way?
No I havent.
Daz 4.9.3.166 even saves a basic Daz created sphere as an obj embedded in the .duf scene file.
Anything new I create or import (.obj) gets saved in the .duf scene in an embedded form ...it no longer writes it out to the auro_adapted folder
I checked an earlier version of 4.9...this does the same, it happened somehwere when I did an update...i dont use the geometry editor tool.
Maybe you could very kindly do a quick test...take 4.9..create a sphere primitive and save it as a scene subset, open that with a text file and see if the geometry
is embedded..and/or if its sent to auto_adapted folder .
That way I would know for sure if its a Daz upgrade change...or something has happened...i cant think what tho..
Thanks
Yes, I get the same. Please report it as a possible bug.
Yep...I thought that might be the case, somewhere this happened, its a big issue because it means if you want to set up several scenes, then the size gets blown out because each scene has embedded obj in it.
Where do I report it?
Also is it possible to download an older version of DS with Iray that does not have this problem, are there any links?...not sure when this happened?
You can make a report through Technical Support http://www.daz3d.com/help/help-contact-us
No, older versions are not available - though if this is blocking your PA work you could contact PA Support to see if they can help.
Hey Richard...thanks yeah...after more tests I found out something.
In older versions (I have one on a back up drive...thankfully) it does not matter if you create a primitive in DS
If you save it as a subset, it will embed the obj file into the scene...so older versions and newer versions of 4.9 do this.
BUT if you created a model in another app save it as an .obj and import it into DS then save it as a scene or scene subset
then the latest version of DS will embed the models data into the scene file...whereas the earlier version of 4.9 writes it to auto adapted
so I have a work around, its gonna take a bit longer but at least I can finish my work...annoying but happy that I can at least deal with this problem.
I am amazed that more people are not complaining about this as it makes creating multiple scenes impractical.
In reality when you first save a scene or subset daz studio should have the option of letting you create a directory where you woyld like to store
obj type data...thats even better than the auto_adapted thing which usually requires a good amount of cleaning up to get the directories working cleanly
but still even thats better than what is happening in the latest DS 4.9 build.
Cheers
Wouldn't saving your modeled item(s) as Figure or Prop asset and then including those in your scene avoid this problem?
Hi...its possible that could avoid the problem...maybe.
But daz Studio has changed its importing and saving scene files somewhere in the 4.9 builds...and another point is that Daz Studio probably should have an option where to place geometry data so the scene file can reference to it when you dave it.
For example with auto_adapted (saving a large scene) you have to delete the ato_adapted reference, delete the legacy obj info refence in both the .dsf and .duf files and add in the
proper references to the desired directory...I have never mentioned or complained about this, because I have a system that gets around this, but it is a feature thats missing in DS.
Plus saving a large scene with nearly 3 million polys...and many different props and instances...this type of workaround can take a lot of time...like days...many days.
I enclosed a render of part of the scene so you can see what I mean.
Bottom line I am happy that I have a previous version of DS 4.9 that does not have this problem so I can finish my work.
Import... > Actions > OK > Default Advanced.dsx > Open
Yes, it would... and that is the point behind fixing what has otherwise been a bug in builds prior to the 4.9.3.x build that addressed it.
I am not exactly sure what you are sayin...you didnt explain yourself very clearly.
To embed the geometry files in the .duf scene files is at best a completely wasteful way to do it.
Fine if you are doing one scene maybe, but if you have several scenes that access the same geometry more or less...
and the polycount is high, then each one of those scenes will be very large in size.
Whereas if the geometry files where sent to auto_adapted and to a custom location, then each one of those scene files
would reference the geometry files with a simple line or two and there be nice and compact.
The way it is now (in the latest 4.9 beta) is each scene is bloated with embedded geometry, so multiple scenes are pretty much
a no no.
I have been building for Poser and Daz since the very early days..I have never seen this Poser...even way way back...sent Geometry to
runtime/geometries Daz sends them to auto_adapted, now that makes sense, the way it is in the current beta makes no real sense.
Once other vendors discover this change there will be a lot more complaints I'll bet...unless you do just one scene.
Anyway I will report it as an oversight/bug etc...