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
Just have to say the morphing/erc system - DS has - is just beyond compare, the more time spent with it. Is like A+.
Had another awesome find yesterday (doing a bit differently than the inherited poser legacy systems that DS uses for morph/erc management) .
Keeping up to date with DS-changelog shows improving FBX support for 'other 3d-softwares pipeline' is still alot of current focus. That said, was nice to see an improvement to aniMate.
Just not easy for any users, like me, who prefer DS for creativity, and not spending time moving assets and compromising with this/that, and learning that software too. Already have enough other 3d apps to know, like Photoshop, Vegas, MD and other.
But everything takes lotsa time to do well (and almost always - lots of money - to do professionally.)
I suppose that's one interpretation.
Another is that DS is going to be a day late and a dollar short, focusing on yesterday's FBX while everyone else has adopted today's USD.
I sure hope you know what you're doing, DAZ.
Suspect (hope so) like most businesses, there is a short-term plan and a long-term plan. Think it's a pivotal thing that bigger shops like Autodesk and Adobe have way more resources to move to the future faster, if they want to.
FBX has been for so long and still is a common standard today for exp/imp. In next ? years will see if FBX is truly replaced by USD. And looking at DS changelog, looks like many FBX issues were ovderdue, for making DAZ assets better migratable to other 3d apps.
Forward looking reminders once in while are always good though.
WHERE IS THE BRIDGE TAB in RENDER SETTINGS??????
I'm trying to use BOSST TO DAZ Cloud.
Have you tried the other Styles, e.g. Darkside? What is your OS? Also, what Layout are you using?
If you put your mouse over the place where 'bridge' should be, it will show up. It's a problem with the colour scheme, makiing the label text the same colour as the background.
New Beta .78 every pose I have tried to load not only takes 3 times as long to load But any parts of my image is touching another ie DM close up poses the character just keeps exploding anyone else have encountered this problem?t
What is exploding - dForce simulations?
Richard No I had a unsimulated dforce garment during a test render to see what the figure and scene would look like. before attempting any simulation .
So could that be my problem although there is no dforce simulation going on the character is still colliding with the non-simulated dforce garment and causing the explosion?
Thank you Richard perhaps a bit too quick to grumble maybe I will have a look at the scene I saved again to see if it is the dforce garment that is causing the problem. If it is I would say that it's a disappointment that a non-simulated dforce garment is causing the trouble.
Also is there any mention of when the spectral colour problem might be fixed?
It explodes only if it is in contact with another object? There shouldn't be anything that would cause that, so I am not sure what might be going on. Would you be able to post a screenshot?
I noticed that at least two latest betas (including current 4.20.1.78 one) crashes on Kennedy's Sneakers asset, again. Either in libneuray.dll or QtCore4.dll library (previous 4.20.1.58 beta) or in nv_freeimage.dll library (current .78 beta). It happens just after firing up Iray preview. Last stable DS 4.20.0.17 works fine. Latest Octane plugin (2021.1.6_76) renders this asset fine on both versions of DS.
This asset uses PBRLayered (MDL) shader on some surfaces, and even conversion to the Iray Uber (MDL) shader won't help with the crash. It being caught by the BugTrap sometimes, but there are also cases, when the crash is being caught only by OS itself. The crash is reported by Windows as a c0000374 exception in ntdll.dll.
I use Win10 21H2 with latest updates and 516.94 NV Studio driver (RTX 3090).
Parts of the BugTrap XML files from previous DS beta concerning the Kennedy's Sneakers:
Load (scene subset) and save (as scene subset) times of clothed G8.1M figure from/to SSD are way longer, than usual, but I'll check it again.
Edit: Indeed, load times are very slow, comparing to current stable DS.
Lots of changes, improvements and more stuff... But the timeline, the interface, the Custom Actions and many other basic tools are still broken.
Still stuck with version 4.12.0.86. Forever as I can see.
Is it deliberate that newest beta 4.20.1.78 has removed add dForce from the scene menu?
It seems like a rather strange choise.
Edit: all good, after I updatedand merged menus.
I've come across what might be a fun bug.
If you have an OBJ with the same name as a DUF file, importing the OBJ actually loads the DUF file instead.
... Can anyone reproduce? (if so I'll report.)
Not in general at least.
Was the obj and the duf in the same folder?
This should cause a scroll icon to appear at top-left of the thumbnail, it's the same companion file behaviour as with poser files to ensure that native settings can be loaded wheer available - see http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/interface/panes/content_library/results_view/start#companion_file
So working as intended then?
Yes.
@Richard Haseltine
With RTX 4090 launch getting closer (October 12), are there any indications how long will it take for it to be supported in Daz Studio?
Will it mostly work just like 2000 to 3000 series upgrade, or we are looking to a couple of months before 2x raytracing and 2x AI power can be put to good use?
I've not seen anything, the earliest I'd expect is either an nVidia dev blog or the change log for the next update, but of course we don't know when Daz will feel happy to integrate that if it has any teething issues.
It's curious, but first two attempts (on first two runs of DS 4.201.88) to render preview with Kennedy's Sneakers actually worked, but the next rendering attempt, just after first one (going back to OpenGL, then Iray again), crashed the program (hence "first two runs").
Now, I only get a message "DAZStudio.exe caused ACCESS_VIOLATION in module "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libneuray.dll" at 0033:0000000043F09B15, mi_neuray_factory_deprecated()+9817941 byte(s)" caught by the program, or a crash caught by Windows, with c0000374 exception, and a "StackHash_1daf" module, within which the error apparently occured. All with latest 517.40 Studio driver.
Converting the PBR Layered shader to the Iray Uber one with "!Iray Uber Base" asset, placed in "My Library/Shader Presets/Iray/Daz Uber" folder does not prevent the crash.
Last stable (DS 4.20.0.17) renders this wearable fine. I'll include the "wearable" asset I'm testing with. This ZIP only has the converted mesh, nothing else, so it still requires the product. The original G8F asset is a revision 1.0 dated from 2021-03-02, according to JSON duf file.
I feel like the bug is somewhere within shader conversion (first conversion succeeds, but later rendering attempts either can't use the converted data, or fails to do it again) from PBRLayered (MDL) to Iray Uber (MDL). I believe, Iray Uber is the shader being used for the rendering, if DS encounters any other kind of shader on an asset during Iray rendering? I included the screen with the said PBR shader.
I just tried installing the latest Beta build via DIM and it uninstalled the previous version but did not install the new build. Reinstalling seems to have worked...
Are you sure the old version was fully closed?
Yes, but I had been running the Release version shortly before updating the Beta, so perhaps the Release version wasn't finished closing; it hangs around in memory for several mainutes after it is closed...
That shouldn't be an issue - they are entirely separate as far as settings and application files go.
I'm getting a very weird issue with the new beta where if I move a character with conforming and parented items to a different xyz translate position, in Iray preview it's not showing these items (like hair) in the new location.
E.g. Character starts at X: 27 and I move to X: 75. In the viewport and in the render the hair will show up correctly with the character at X:75. However, in Iray preview the hair and other items is still showing up like the character is at X: 27 :|
I've updated the graphic card drivers and I'm using studio version and not game ready. Anyone else getting this?
I've not seen that. Have you tried turning off and on in Iray preview?
I too have been having this issue with strand based hair
If I turn off Iray preview and then turn it back on it fixes itself. But that's a bit of a pain in the butt to do over and over again. It does not seem to be related to Nvidia iray drivers as I'm not having this issue in 4.16
It is quite possible that I don't understand the recent changes to Update Base Geometry, but when I update from a DS exported OBJ, it always opens with a bizarre custom percentage. I am running DS 4.20.1.91 Public Build.