Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
If you frame scene and end up on the moon, you might have the "wrong" tool selected. Something like this happens to me if I have the surface selection tool selected instead of the node selection tool selected.
Ah, thanks. I had not considered that interaction.
I too read the Iray developer's manual. It is clear that IScene:set_dirty() call to invalidate instance transforms is needed if instancing_shift_camera is set to false (i.e. if automatic shift is disabled). The manual says itself "This is recommended if the camera was moved a long distance...", and this is exactly the case that should be handled in the DAZ's code. Framing the figure with large XYZTrans or manually moving the camera to a large scene XYZTrans should trigger it, not to mention starting to render new animation frame (not sure if the latter is handled, I didn't test it).
The reason why this shouldn't be a GUI button is that you as a user shouldn't be expected to know about this and you couldn't use it when rendering an animation anyway. Say you have an animation of a vehicle traveling through the city with a passenger inside and the camera following it. If there is no set_dirty() call before rendering each animation frame, the error would in theory accumulate and you would get worse artifacts as the animation progresses.
Maybe we shouldn't call it a bug, but rather an omission. Regardless, I believe DAZ should fix it.
If there's nothing selected of the entities the tool works on then the frame works on everything in the scene.
Can anyone who has downloaded the new .09 beta tell us if this fixes the issue with opacities in iray? I skipped out on .02 because of that and don't feel like 14.14 if that issue still exists.
Thanks.
I just updated to 4.15, and now when I attempt to render, it runs for about 12 seconds and then says it's done, but it hasn't rendered anything. I'm running Windows 10 with a GTX660 graphics card. Here is my log output:
2021-02-12 16:39:23.241 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating geometry.
2021-02-12 16:39:23.241 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating motion transforms.
2021-02-12 16:39:23.241 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Importing scene graph.
2021-02-12 16:39:23.241 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Importing geometry for motion time 0
2021-02-12 16:39:29.357 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Geometry import (1 triangle object with 10197k triangles, 0 fiber objects with 0 fibers (0 segments), 1 triangle instance yielding 10197k triangles, 0 fiber instances yielding 0 segments) took 6.116s
2021-02-12 16:39:29.359 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating materials.
2021-02-12 16:39:29.685 Iray [INFO] - MATCNV:RENDER :: 1.0 MATCNV rend info : found 614 textures, 0 lambdas (0 unique)
2021-02-12 16:39:29.709 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Emitter geometry import (1 light source with 2 triangles, 1 instance) took 0.000s
2021-02-12 16:39:29.709 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating environment.
2021-02-12 16:39:29.974 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating backplate.
2021-02-12 16:39:29.982 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating lens.
2021-02-12 16:39:29.982 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating lights.
2021-02-12 16:39:29.982 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating object flags.
2021-02-12 16:39:29.983 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating caustic portals.
2021-02-12 16:39:29.983 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Updating decals.
2021-02-12 16:39:29.995 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Using iray core convergence estimate.
2021-02-12 16:39:30.000 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Allocating 1-layer frame buffer
2021-02-12 16:39:30.012 Iray [INFO] - IRAY:RENDER :: 1.0 IRAY rend info : Using batch scheduling, caustic sampler disabled
2021-02-12 16:39:30.012 WARNING: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(359): Iray [ERROR] - IRAY:RENDER :: 1.0 IRAY rend error: Cannot render: found no usable devices.
2021-02-12 16:39:30.012 Iray Render error: Invalid parameters (NULL pointer).
2021-02-12 16:39:30.252 Saved image: C:\Users\Lee\AppData\Roaming\DAZ 3D\Studio4\temp\render\r.png
2021-02-12 16:39:30.260 Finished Rendering
2021-02-12 16:39:30.345 Total Rendering Time: 12.95 seconds
Any help would be appreciated.
Oh, for Pete's sake. Sigh. Okay, here is the inevitable question: How to do I downgrade back to 4.12?
If you didn't save a backup, the only legal way is to ask Daz for a copy. Submit a help request. Good luck.
Thanks a bunch. I just sent them a request.
Why do people always neglect to back up their install files?
I have Daz studio files dating back to DAZStudio_3.1.2.19_Win64; just copy your zip files located in the DAZ 3D\InstallManager\DOWNLOADS directory to anywhere you want... You can also copy your install folders to any directory as well!
I don't get it either. My backups go back to Version 2. No zips back then so exe files make it a little easier. Most important save the dsx files that go with the zips.
Because:
1. It shouldn't be people's responsibility to keep backup copies of previous versions of software for actively developed and maintained software products, especially for digitally distributed software.
2. Because truly backing up and restoring is not as simple as you make it to be -- you also need to backup DAZ Studio registry keys, interface layout configuration files, your asset database (I hope you know how to backup PostgreSQL database), and do all that every time before installing an update if you really want to be able to fully restore the previous state.
IMO, DAZ has no excuse not to have a reasonable number of previous versions avaiable for download behind a login page instead of making people request downloads of older versions all the time. I am sure they have a pretty good telemetry of which versions are used the most. I have a number of paid software products for which I have an option to download all released versions from the one I bought to the latest update my license covers.
Much better question would be -- why people update to new software versions without first reading what has changed to see if it will impact their workflow?
It is as you cannot get it legally, other than opening up a ticket, and even that is not guaranteed...
Yes, it is, as you do not need to back up the registry keys, and interface layout configuration files, your asset database for each new install of a newer version is used between the different versions, all that's left is to simply install the next version via DIM, the installed folder is self-contained, I know as I have studio 4.6 and 4.7 already in use alongside my 4.15 version; Daz studio install folders are 100% portable!
In fact, to prove it, I just moved my 4.15 folder to another drive and it works fine! If you already have the asset DB backed up, (Just open up a new directory and store it in any folder you want, it's that simple!) as far as the ILO config files are concerned, they carry over to every and all versions no matter what version is installed, I even have a backup of that in a custom directory!
You don't even have to use the Library folder structure in my doc/public folders; I actually use the content folder as a personalized folder in a custom directory independent of the "my documents" folder!
You are not bound by the default program files/my documents folder at all!
I could not agree more, but we cannot discuss it here as it's against the TOS, but yeah, that's why it is all the more reason for the backup because Daz doesn't allow for previous versions!
This is another thing that people should be responsible for!
@Takezo_3001
We'll agree to disagree on the responsibility part -- I believe that a software developer has the responsibility to not break stuff with updates, and if they really have to make a breaking change like in this case where 3rd party is removing support, they should provide previous version for download free of charge, no questions asked, no tickets needed.
Note that I am not saying that people shouldn't backup software installations at all -- they should, but backup drives can fail (surprise, even if you also backed it up to OneDrive/DropBox/GoogleDrive you can lose access to your online account and thus to your online backups), and not everyone has your level of technical expertise with computers.
Agreed, although I understand folks forgetting once, but I've seen it happen repeatedly. They just don't bother.
Just downgrading to 4.14 doesn't fix my problem. I get the same result when I open the 4.14 that I have re-installed. This is after uninstalling 4.15, deleting everything I can dfind in app data, program files, registry, roaming, etc.
For the last three days, when I open DAZ Studio, 4.15 or 4.14, it loads and i may be able to close or open a tab, but after that it locks up and all I can do is close the app.
I wholeheartedly agree that a lot of software companies both should and do provide software backups, but when they don't we need to do it ourselves, and yes HDDs can fail, but so can CPUs, GPUs, and PSUs, but we don't back up our software on the assumption that our HDDs fail, we back them up so we can feel safe to upgrade to current software with something to fall back on when the upgraded software fails...
Ideally, I would love it if all software companies allowed for legacy installs, but that's not gonna happen anytime soon, maybe that's something we can all open a ticket/file a suggestion for future programs to provide legacy versions!
Yeah, it's pretty much like clockwork; every time a new studio comes out that someone requests a legacy version of Daz Studio, you can at least zip up your old install folder and copy it to another drive before the upgrade, as the DIM would have installed over that folder if anyway!
Couldn't have said it better myself Johndoe, Thank you!!!! We shouldn't have to back up anything when updates become available. No one anticipates having to deal with problems.
You don't have to back up anything - unless you think you might want to roll back to an earlier version.
@Nick_1939
Also note that the BETA version doesn't replace the release version and will use the exising Library paths.
It uses the settings in:
C:\Users\insert-name-here\AppData\Roaming\DAZ 3D\Studio4 Public Build
The CMS paths are in ContentDirectoryManager.dsx if they have been modified. Otherwise it looks somewhere else, possibly the registry. It obtains the "current" CMS settings from that mysterious other source, so to ensure you don't lose CMS settings go to the Content Directory Manager by right clicking on the "Content Library" tab and selecting it, then select the "Current Directories" entry (the first one) and make a copy with Copy..., rename that to something appropriate, e.g. Backup20210214.
To back up the settings archive every ".dsx" file in that directory. To set the Public Build (Beta) to the same as the General Release copy all the ".dsx" files from DAZ 3D/Studio4/*.dsx To restore the Content Directory Manager settings open the Content Directory Manager as above, select the check(dot) box next to the name you gave the backup set and click accept. Exit DAZStudio and the setting will be saved as the "Current Directories" one. You have to do this without -instanceName; that option (at least with the default settings) prevents you changing the .dsx files.
C:\Users\insert-name-here\AppData\Roaming
can be replaced with
%AppData%
OK, but in my case that directory is empty... I assume this is only valid if one uses DIM, right?
I used DAZCentral to install and update and reading this discussion it scares me, things like "Most important save the dsx files that go with the zips." or " If you already have the asset DB backed up" or " as far as the ILO config files are concerned" or "You don't even have to use the Library folder structure in my doc/public folders".... I mean my public DAZ folder is empty...
Of couse I have all files regulary backed up in my NAS, but honestly I would have no clue what file exactly I would need where, so most probably I would just restore eveything called "DAZ" I'd find. Or did I miss the "official" way for backup, other than fiddling around with files?
A company that provides free software is not obligated to provide anything in the way of backups for said software. They provide a permanent backup of all purchases made.
A user makes their own choice; it is their responsibility as an adult to to make sure they have what they need; or as an adult to ensure the minor they are responsible for has what they need.
What happens if something happens to Daz? So I backup my purchases and I have multiple versions of studio backed up because I have a lot of cash invested in their products.
Regardless of a person's opinion of what should be done, the reality is that they don't, and even if they did; personal backup adds redundancy. It also adds convenience.
I also backup the various registry keys and folders.
Yep, agreed!
I must also add that I don't mean to force users to backup their DS. as they have the freedom to not back up their programs if they choose not to, but they should not expect that Daz has to provide legacy versions as they don't by default and it's at their discretion whether or not they provide it upon request...
The main reason I even brought it up as I was both constantly reading about people fretting that they cannot revert to a previous version, (The sheer frequency is like clockwork every time a new vers comes out.) and remind people to bypass the issue by backing up their versions so they won't have to deal with the issue of not being able to revert the changes... as Richard pointed out, back up your DS if you want to revert the changes...
umm,
I would strongly argue against the assertion that "it's the same people" that are suffering this repeated lesson related to updates and the backing up of previous installations/installers. Rather, I propose the repeated messages are coming from intelligent but confused *new* users, simply figuring out the "DS way" the hard way - just like the rest of us have.
Kind of an ages-old initiation ritual at this point, you might say. heh.
Relative to end-users, the current DS Application update system is auditably anti-revision-control in its design. And I'm not saying or implying it is designed with malice or ill intent. This is a statement of fact, based on evidence.
It is simply impossible, as designed, for the users of DAZ Studio to engage in any serious form of *efficient* program/application revision control and rollback based on the installation file archive information available to them at any given moment.
Oh sure, you can describe for me the steps I should take to ensure a complete backup right now, etc. Please, spare me. Forum posts with that info abound for this very reason - and in spite of the good souls (myself included) who try to warn and prescribe the proper work-around to DAZ's refusal to help us protect our application history, the problem repeats at virtually every update. Again, and again, and again. This is also a fact.
Cure the problem, not the symptom.
I've got 30+ versions of "IM00013176-02_DAZStudio4xxWin64bit.zip" and all of the DAZ-sponsored plugins (like "IM00010673-02_DecimatorforDAZStudio4xxWin64bit.zip") that I manually copy and store in named and version numbered folders because *I* certainly can't tell exactly what version each file is without ripping it open and 'grep'ing through the files to figure out which is which.
And neither can you.
Outside of personal full-system backups before each update download session, the current DS file-naming system has no practical user-facing versioning of the files to be backed up.
And no, checksums or other file-parsing/diffing techniques are not viable 'end-user' solutions for this situation. Name the files distinctly and let the user keep or remove them at will - even if by using a checkbox in the DIM/Connect/Central interfaces. That's all it would take.
And based on the internal behaviors of the Developers, they *certainly* understand, and practice, great revision control! To that end, their own plugins that haven't internally changed code between versions, will choose not to load if their compiled in versioning doesn't exactly match the updated DS core application version. Nice. And, none of the PA plugins suffer this effect - DS4.x PA plugins that are 8 years old work fine today - go figure.
So, this system design isn't based on ignorance - it's an intentional choice.
Yet, while I may disagree with the DAZ policy that makes rolling back and access to older versions difficult, I understand it.
I understand that supporting 30 older versions of a 'free' program isn't cost effective for *any* business where costs like this will be accrued by the loss-leader (DS).
Perhaps I would simply make the older installers available in an archive, and release them with a clear 'no support' policy - but that's just me.
But never, across the industry and years of software development and usage, have I seen a system that makes it so difficult for
a) a user to even *know* that he/she should cover his/her interests (old versions getting silently replaced), and
b) make it so overtly difficult to actually do so, and to recover from errors in that effort.
No, the problem here isn't the new DS user who didn't back up his/her files.
Nobody can argue the fact that after all this time, somebody in the DAZ release management group has long-since made an operational choice and *still* thinks it's the right choice after all of these years, in spite of all of this constant/repetitive forum feedback from intelligent new users learning the same old lessons again and again, and in spite of all of these support tickets requesting rollback versions. But, perhaps the release team is right in their choice - based on what metric and what numbers - who knows?
That said, I would love to see see how many of their support hours are spent helping users roll-back to previous versions, and even *more* curious, how many of these new DS users simply went and installed Blender after witnessing how this all operates. Too bad we'll never know, eh? Based purely on forum participation, it's clearly a repeating pattern for those that would look - both the problem... and the 'solution'...
And FWIW, as well intended as it may seem, effectively calling the intelligent but frustrated DS newbie users 'stupid' for not backing up their files, rather than acknowledging and maybe addressing the problem as it really stands, probably doesn't generate as much community goodwill to the new users as one might imagine, but perhaps the composition of the community simply is what it is.
That many of us have reverse engineered and shared the details required to do the required backups may prove some tidbits of wisdom, it doesn't make the fact that we need to do so *in this way* any less silly.
The movie character Forrest Gump had a good line about stuff like this.
best,
--ms
4.15.0.9 seems to be even worse when it comes to geoshells.
In Iray preview and render even if the figure is not moved very far (-415 ZTrans), the geoshell at 0.010 offset doesn't display correctly. What's worse, if you put the figure back to 0 ZTrrans it still doesn't render correctly until you turn the geoshell visibility off then back on.
All views on the making of back ups and the availability of old versions have at this point been thoroughly aired. Please turn the conversation to other areas, remembering that this thread is intended for discussing the current Public Build (Beta).
I overwrote my 4.11 last update accidently and have apparently lost the one I had backed up from CS
so I must be one of these stupid people who make mistakes
update apparently I can still download it though so thats good, I better hang on to this one
and I crossposted so apologies to Richard but not to Johndoe
my posting about an ongoing issue does not affect him in any way ...yet