Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I don't disagree, but it sems that nVidia's priority is to simulate reality rather than offer non-physical aids, so we are left looking at the available workarounds.
Available workarounds and the purchasing of alternatives that will work with 4.2, you mean. Is Daz planning on refunding anyone who bought Ghost lights and Probe lights as their latest release has rendered them essentially non-functional? I would think not. It's not like they are the only things I use for indoor lighting. I use emissive surfaces on any light or lamp prop, I have two spots mounted on my camera and also use point and spot lights. But ghost lights are fast, easy to use and reliable
...I've frequently used auxiliary light sources similar to how a photographer or filmmaker does long before the advent of "ghost lights". True takes a bit of planning and some experimentation, but I've been around film sets, seen how they do it and the short video above explains the basics of this very well. The one thing filmmakers and photographers don't have are "invisible" light sources to work with so they need to find ways to keep the light equipment out of the camer's view but still create the desired effect such as fill, directional, and mood lighting to achieve the desired effect.
The one issue with a camera in an interior setting is that it's aperture does not automatically adjust or compensate like our irises do to changing light conditions. I can be sitting inside of a place an looking out a window and clearly discern both what is outside and inside as the eyes continually adjust between the darker environment inside and brighter one outside which a camera cannot do, once the fstop is set that's what you get.. So to photograph or film a scene on the inside where there is say, a window in the background (such as in the bar scene above), if the aperture is adjusted to the interior lighting, the light coming though that window will be "overexposed" washing out any details of the outside and creating a distracting "hotspot" unless additional lighting is used inside to help balance the interior to the exterior light values.
Basically with Iray, or any other PBR engine, one has to think more like a filmmaker or photographer.
Three years of real-world photography lessons have been justified with this sentence. Never imagined that happening. Wow. My condolences to everyone who used ghost lights.
...+1
When I did use them, I created my own (not very difficult), and yeah, it made the workflow for a few scenes a bit simpler but not lamenting it. I was a little more concerned by a thread in the Commons that somone mentioned mesh lights were not working in 4.20 when it turned out to be a number of the lights provided with the set were "ghost" light disks and spheres.
I've always tended to use my own light setups even when lights are provided
Oh man! I was going nuts wondering why a scene I was working on suddently was much darker!!!!!!! :( Wish I at least upgraded inbetween scenes.
I've looked through this thread and didn't see a solution to this. I reinstalled 4.2, cleared all the AppData folders, and turned off Octane. It's moving much faster now. HOWEVER, the danged thing won't save my layout. Whenever I restart it all the wrong tabs are active, sized wrong, and defaults to Fillament, which is not my typical.
Any solution to this? I tried saving my workspace as a custom one but looking for something to work on startup.
Non-saving of layouts have been fixed, and should be available this week.
ROFL!
:: clang ::
:: Director yells his favorite obsenities ::
Gaffer: "What happened? You ok?"
Director: "I ran into one of your damn ghost lights again!"
Just a follow up on my last post.
I haven't been able to reproduce that denoiser restarting problem.
At this point I am assuming it had to be GPU temperature related.I admit I didn't check my GPU temp at all when this was happening.Maybe this should be logged?
I was also seeing UI elements disappearing and reappearing in the Studio UI (UI corruption?) at the time.
Testing the same scene several times this morning and all is working.
Sorry, but I personally don't find this acceptable in any way, shape, or form. I have been "dealing" with it for 3 days and now and I am already totally frustrated with the whole issue. Yeah, there are workarounds but 1. They require significant effort in order to recover existing lighting compositions, 2. They are not accurate in terms of recovery, and 3. As you can clearly see in the postings, they are prone to user error.
I have spent years develping light schemes and many, many rely on "ghosted" emissive lighting (including actual Ghost Lights). Hundreds of scenes that I hoped to reuse. I have over 30 scenes started in the past two months that I need to complete in short order. All of this required significant effort in order to produce the desired lighting effect. Every time I load a DAZ-purchased propset, I will to have examine it carefully to see if the PA included a "ghosted" emissive primitive.
In terms of DAZ and nVidia, I really don't care where the issue orginates. And I don't care if it is essentially a defect fix on the part of nVidia. "It's not how the real life luminance works"? I don't care--what I had was working! The end-users should not have to bear the bulk of the burden in "dealing" with it.
Instead, I contend that in order to properly serve it's customers, DAZ should build into DS a solution that allows us to choose whether to use our existing lighting schemes, unchanged, or to utilize the nVidia mod if we choose to do so. If not this, someone please explain to me how it is okay for DAZ to simply pass this problem on down to the PAs and end-users. I have spent more years in software development and software testing than I care to count. We would never, ever have considered doing such thing! No way they should have had to pull Ghost Lights out of the store.
I believe the correct solution is not a piecemeal change to our existing light objects. The solution should be built into DS so that we can continue using our existing lighting if we choose to. Most of us know full well how critical lighting is in producing good renders. Hence, most of us spend considerable time in getting just the right lighting. All that work has to be re-done? I rarely light a new scene from scratch. I load and re-use exising lighting schemes just about every time I start a new scene. Sometimes, I load an existing scene, replace some unlit content in the scene, and then render. But not anymore. This is major workflow disruption. I absolutely cringe at all the unplanned work that will result from this.
Ever bought a car that developed a problem while still under warranty or that requited a recall? Chances are that the offending part(s) are supplied to the automotive OEM by a 1st or 2nd tier supplier. Who do you blame when your car no longer works correctly? The supplier? Who fixes it? Does the automotive OEM send you a new motor with instructions on how to pull it and install a new piston? Do you even know or care who made the part? The same applies to software developement.
It's common practice everywhere for software companies to rely on 3rd party developers for software content. When I was developing software, we always relied on 3rd party suppliers for embedded libraries. I can't begin to count the number of hours that I spent working around issues in supplier software that should never, ever be passed onto the end-customers. If I did that and blamed the supplier, the customer would be outraged and rightly so!
If DAZ doesn't understand my argument then perhaps they should understand the potential economics. With every hour we spend working around new DS issues, our frustration with DAZ grows. I guess it wasn't bad enough that we had to "deal" with all of the figure compatibility issues over the years. It just serves to drive people away. Honestly, I don't see a benefit--for anyone--that outweighs the cost of DAZ taking the current approach.
I suggest submiting tickets until DAZ gets the message. If there is another, more effective way to communicate our concerns, then please let us know. We need a mod baked into Studio.
Using your car analogy, the broken part originally worked as intended, hence the warranty. It would be ike you teling the dealership, "I don't care that x wasn't meant to effect y. I liked the improved performance it had on my SUV and demand that you put x back the way it was!"
What DAZ (the dealership) is saying about Ghost Lights is that the functionality that allowed them to work was never intended. It was a bug that nVidia (the manufacturer) has now fixed.
I hear and agree with you. I haven't updated yet to 4.20, but I did find this:
https://www.daz3d.com/forums/discussion/548061/iray-ghost-light-fix-dse-for-daz-studio-4-20-o-later#latest
Basically, the script does the work in fixing the ghost lights to a large extent. You still have to up the lumens into the billions, however. But... I just tried this... most of my interior light balls are at temp 4000 and lumens 300. I made a light ball, applied the temp and ran the script and made the lumens I think 1 billion. Maybe 1 trillion, I foget which. I saved the light ball as a subset. If I merge it into a scene with light balls and replace those light balls with the scripted subset one, it works great. So the workareound is to create a bunch of lightballs as subsets, and then use them as you will.
Again, apologies, but this argument and "It's not how the real life luminance works.", I find to be the most absurd of any I have seen in the past few days. If DAZ knew it was a bug and that it could potentially be fixed at some point, why on earth was anyone allowed to implement? If you did not know it was a bug, why not? What about support for point spotlights? Is that a bug? I can't find those lights in the real world. Will that be taken away at some point (rhetorical)?
I get the impression from the light purists, that only "real world" lights are acceptable. What about werewolves? Those are sold in the DAZ store yet none (to my knowledge) has ever been found in the real world. To me, this "It's not how the real life luminance works." is simply a flawed argument, at best. If I didn't know better, I would suspect it's just a way of excusing DAZ for not implementing an acceptable workaround.
Of course photographers don't have invisible lights in their tool box (yet). But if they did, does anyone really doubt that they would hesitate to use them?
Invisible emissive lights are still available and can still be made to work with some effort. I know for a fact that there is a workaround that will allow actual Ghost Lights to still work (without "fireflies" and without the mesh showing up in reflective surfaces). What we have lost is the abilibty to use our existing lights setups. I simply do not believe that DAZ cannot find a way to support it's customers properly.
So ghost lights were never meant to be. Does this mean that some variation will never show up in the DAZ store again?
I just can't wait to see what functionality we are going to lose in DS5.
nVidia does intend iray to mimic physical reality. That, presuambly, is why they fixed the non-multiplication of opacity and luminosity. Daz had no ral way to know they would do this, and has no way to compel them to undo it (though I would point outt hat there does seem to have been a degree of softening, judging by the change log). It is, of course, an unsatisfactory situation but we don't, sadly, seem to have the collective weight to get it fully changed.
In my experience with software, the old saw usually applies: "Where there is a will, there is a way". Is there really a will?
No one has clearly stated the problem. I still don't understand why a light doesn't fulfill the functions. Lights do not have geometry so they are invisible (as I understand it). What is the problem with a light that is in the camera field? It's a somewhat weird and definately non-physical object however the problem is that it is a big black pustule when it appears in the scene (and a white one in any reflection). How come an object without geometry blocks out parts of the entire scene?
Since DAZ Studio lights are already horribly non-real why not fix the problem there, and obviate the need to exploit a very clear bug that basically ruins [polite] the behavior of real world emissive objects. Ghost lights only got invented because DAZ Studio lights don't do the job and, while the jobs is incredibly, shin damagingly, perverse, the DAZ lights are already perverse.
Just to make it clear what I am talking about:
This is a DAZ Studio light sitting inside a sphere. The sphere is twice the size of the light, yet it is completely invisible because I set "refractive index" and "refractive weight" both to 1. The black thing is the light. You can see the reflection in the Iray Uber green plane to the left; this is expected, define how a light can work if it doesn't produce reflections in the surfaces it impacts. The problem is the black thing.
What exactlty did you forget to do? This has been driving me insane. The layout shows up in my "user layouts" but I still can't get it show up in "select layout."
In my opinion this is simple. DAZ is mainly responsible with their customers and PAs to keep the items in the shop working as intended. If a new version of iray breaks compatibility in any way and there's no possible workaround, then just don't upgrade iray. Or is DAZ forced to upgrade iray by contract ?
Otherwise the only solution for us customers is to don't upgrade daz studio, so renouncing the new features and featured items in the shop, to keep compatibility with the previous items. That at a certain point in time will become a mess anyway especially for new customers because you don't know anymore what items work and what don't.
This is the sort of shennaigans we could do in biased renderers. It's hokum, real world lights all have to have a source!
...But if you want to do that sort of malarkey, Iray let's you use the 'Matte' property and the Emissive Sphere becomes a ghost!
...so looks like I'll be staying with 4.16 for the time being as about the only new feature of interest is the volumetrics thing and until such can be created totally within the Daz, no hurry to upgrade given the bugs others have been running into with some of the basic functionality.
Besides, learning the ropes of modelling in Blender is more than enough to have on the plate for now.
It's the same reason I'm still on 4.12 since its launch.
There's no way to work correctly on any release after that...
Turn off render Emitter and the back of the light will go away - if you give the light a non-point shape then it does have geometry, though being able to hide it is cerainly an example of nVidia's being willing to be non-physical; fortunately it's a documented feature, unlike the one ghost lights use, so shouldn't be going away.
I get what he is saying. I used to have SLI running Studio plenty fine. Both cards would render. No, it didn't use double memory (which nothing did in SLI), but the cards would at least still work. If people are not able to render anymore with SLI (not NVLINK) bridges, that is new.
It looks like I may have confused you, I was refering to the volume shader that I had unzipped to the wrong location. As for the layout bug, it does write a file to the user layouts folder but the program cannot see it. I believe there is a fix due this week.
Switching off features (or exploits perceived as features by the end users) is one of the dumbest things a software house can do. Give the end users what they want and enjoy the profits!
Daz is breaking compatibility with existing products without a clear demarcator (this is an incremental build number, not a new major release).
If I created a scene in Daz Studio 4, I expect it to work as is in any subsequent release of Studio 4. If the render engine has changed, Studio should be able to autofix the changes and spit out an identical render image, irrespective of changes to the engine.
Daz could do a few things about this mess:
- Stop assigning the "Compatible with Daz Studio 4.CurrentReleaseNumber" to products in the store, and just list the fiorst and last compatible versions
- Make a selection of Studio 4 releases available for download
- Ship 2 or more versions of the render engine with Studio, and allow the user to select which one they want to use
- Ask nVidia for a toggle that enables/disables ghost lights in the name of consistency and sensibility. Nobody wants their PC to replicate the real world exactly, we want a better version of reality with ghost lights, dragons, mages that can fly etc
As far as I have understood and read on these forums, DS with Iray uses all installed, compatible Nvidia cards as long as the scene fits on VRAM of all the individual cards. No need for SLI
NVLINK on the other hand allows similar cards to combine their VRAM for textures.
EDIT: No, the matte property on a SpotLight does nothing (the pustule is still there) and on the sphere (which you will note from my previous images isn't visible because of the refractive weight) setting the matte property on kills the emission too. I tweaked the HDRI ruins environment map intensity so that it would be possible to see the illumination from the sphere when I added a red emission to it. First with Iray matte switched on on the SpotLight but off on the (now emitting) sphere (this is all the same scene as before - nothing added, nothing removed):
EDIT: The problem is that Iray Matte really does remove the specular reflections and this makes the illumination much dimmer (so it is there but almost impossible to see).
It's dark (ruins is at 0.1 not the previous, default, setting of 2) and you can see the sphere, it's reflection (just) and the lighting afforded by the sphere on the white horizontal plane. Then:
The only change here is to turn the Iray matte property on the sphere ON. The emission has gone - no red on the horizontal plane. Just to make it clear what is going on with the sphere, these are the currently used "surface" properties:
So no ghost light, if "ghost light" is defined as a light source that does not participate in the render with path-length is 1 (to the source). Apparently there is also a requirement that ghost light doesn't cause specular reflections; somehow the rays that encounter it after hitting a surface with a non-zero "glossy reflection" are supposed to be discarded as well. ghost light is a weird flat light...