A quick internet search on radiator placement offers two possible reasons (which suggests that no one really knows) - that that space was most likely not to be used by anything else, and that it was the coldest spot and so gained most from the heat. I find the first most plausible.

Togire said:

There is a problem a problem with the "Femme Fatale Bundle". https://www.daz3d.com/femme-fatale-bundle

While it appears in some sale list and is properly displayed on a search https://www.daz3d.com/catalogsearch/result/?pp=40&q=femme+fatale+bundle&mature=true&s=score&p=1&guid= the link leads to an Ooops page.

Where is it being listed?

There is a problem a problem with the "Femme Fatale Bundle". https://www.daz3d.com/femme-fatale-bundle

While it appears in some sale list and is properly displayed on a search https://www.daz3d.com/catalogsearch/result/?pp=40&q=femme+fatale+bundle&mature=true&s=score&p=1&guid= the link leads to an Ooops page.

I don't know if there is a way, but it would be nice to have better features to filter out products. I recently bought some things and cannot find them, because the library gets bigger and bigger. I try to rearange the products, by their purpose. But in Order to do that for products I already own, I have to find the ones I already got too. It would be a help to know if there is a way to let's say filter about "modular" stuff. I know for sure the shop does not really crawl to the description, because I bought something that has sepcific words in it and the product does not pop up, if i search it. In the product library it's the same. So it would be nice, if this neat function to search something could be able to do that... 
But, in case there is another way, please let me know! 

The point I wanted to make is that the argument that an iteration is doing more work kind of falls apart when CPUs are clearly not impacted the same way. Plus the renders demonstrate this as well.

It is apparent that the Iray dev team is focused heavily on caustics, and I can understand that. Calculating caustics is very hard. Enabling caustics in past versions of Iray killed render speeds, often doubling them or more. So having caustics improve is a good thing...but I don't believe it should come at the cost of general performance overall. While caustics are nice, most people don't take notice of this effect, and if you don't have the types of glass like materials that benefit from caustics, killing performance for caustics is a waste. The most visible impact from caustics is that the room has a bit more ambient light. This can be replicated with simple tone mapping, while rendering significantly faster (in 4.16).

My belief is the performance drop is down to a simple mistake. They already admitted that they made a mistake when they claimed to fix the performance loss. So I believe that they still have left something unoptimized, and this is wasting resources during rendering. If they fix this, it would benefit the caustics, too, because the base renderer would be optimized, not just the caustic sampler. So it is very much worth their effort to find the solution. This is a highly competitive industry, they have to be better than other render engines, period, or they will fail even if they have Nvidia's backing. Daz Studio is obviously not their only partner, though it is the most visible partner in every search for Iray.

When you start a CPU only render, it starts right away because the scene is already in RAM where the CPU accesses it. To render on GPU, it has to be sent to GPU, and this process involves several tasks, such how CUDA converts the textures into its own proprietary format, and compression. I am thinking something with this step is involved with the performance loss. It would explain why the CPUs appear to be unaffected.

I have tested compression. The default compression settings are very aggressive. I set them so that no texture at 8K or under would get compressed, all the textures were under 8K. The render will load faster, which is logical, but it didn't impact the render speed much. It did seem to render just a hair faster, but the margin was so small it could be within error, certainly not enough to explain the issue. So compression is not the problem. But we still have the translation Iray performs. I don't think we can test for that.

OK, click the gear icon on the slider for the problem shape>Parameter Settings, copy the Name (not the Label).

Help>Troubleshooting>View Log File, then search that for the name you just copied to see if there are any errors or warnings related to it.

Dartanbeck said:

Richard Haseltine said:

Because the Clear button is the function that all simualtion engines will support, making it Clear Selected might be problematic with futue additions. I am in the habit of using the pane's option menu, via right-click on the tab, since that is available even if the pane is not the active member of its group.

I truly understand, but it would be nice if there was an option next to "Freeze Simulation" that allows it to be frozen against Clear as well. However, I'm still a very happy dForcer. I do have those times when I lose bucket loads of time, but that's just life. Between the weight editing, surface dForce properties and simulation settings, I think dForce is a pretty slick solution. And as for it being in Daz Studio, it's still brand new - when you thnk about it.

I notice that you are very generous in your praise but you do make a similar point to the one I made about "freeze" should be absolute. As for dForce, I can only compare it to the only other cloth sims I have used (Marvelous Designer and VWD) and both have/had huge advantages over dForce. I mean being able to manipulate the cloth while the simulation is running and also both being so much quicker. Unfortunately, VWD crashed my DAZ Studio repeatedly and we never figured out why. So I think that, as with some other aspects of DAZ Studio, the technology needs to catch up.

I would add that we all want DAZ Studio to be the best it can be which is why so many posts on the forum concentrate on what we think could be improved. 

RuudL said:

I was actually already thinking about posting my developer environments on both Windows and macOS. But I wasn't sure anyone would be interested. So I had put it on the back burner. Currently it's just a collection of notes and it will take some time before it's ready to be posted.

I'll post it in the 'Carrara SDK Developer Discussion' forum. To me that's the most logical place to post it.

+++

no rush on this... that said, *any* knowledge we can record on such tools might help those with familiarity and interest in coding to put together a local workspace where they/we can play/fix/tweak existing plugins and perhaps grow some new ones. Many of us know the nouns and verbs of coding in a specific environment, but few likely know the secret sauce to coding for Carrara (which compilers, library versions, carrara-specific plugin conventions), and having such notes as you mention might really accelerate the immersion process - rather than the now-unlikely "RTFM from scratch" approach.

Most of our collective progress relies on the "shoulders of giants" and the willingness of those generous giants who would give us that leg up.

I'm certain anything you would cobble together would be greatly appreciated by current and future Carrara-ists - even if basic in form!

best wishes and TIA,

--ms

Richard Haseltine said:

Are the the Manifest files still there, in the Manifests folder? There are various things that can break that (mostly local - over-zealous security software, hardware issue). The code for handling this area has not changed so it is unlikely the update is to blame in itself (I did have Malwarebytes decide that updating the thumbnails was a ransom are attack and delete the whole application, had to adjust its settings to resume that process)..

Nothing changed but the IM.

I figured it out. Not sure if this is a bug or feature but if feature it's kinda bizarre. IM can't read hidden folders/files. Hidden is a user facing setting. I enabled it to stop Everything displaying swathes of unrelated daz content on every search. This didn't obviously impact the previous version but based on the implication that code doe handling hasn't changed, I'm guessing that was because nothing had refreshed yet.

Everything is a superior search index for Windows with an unfortunate--non google friendly--name. It can be set not to display results in hidden and system. Everything itself had nothing to do the issue. I only mention it to explain the use case of hiding Daz files that have no day-to-day need to be user exposed in file browser or search.

Daz Studio has no issue with hidden files. I presume IM is using some part of the Windows file management API intended for user display rather than programmatic file access because, as with Studio, it shouldn't matter to IM if the hidden flag is checked or not. At least, no obvious reason for it to matter comes to mind. Thus kinda bizarre.

cridgit said:

butaixianran said:

The bad part of Daz's C++ plugin's document is not the API part, is the quick start part. 

The SDK document is very old and asks us to install very old version of Visual Studio.  Many developers won't do that, they just want to use latest development tools. If a developer's other projects can work with latest dev tools, they won't install an old version just for Daz. So, if Daz' SDK can not work with VS 2022 and no document about how to make it work, they just left.

As I searched in forum, SDK doesn't work with VS 2019 or later any more. And no tutorial about how to make it work with VS 2022. I won't install VS 2010 just for Daz, so like other developers, I just left.

Since VS 2022 won't work, I think Daz need a new quick start document for SDK dev, based on VS Code 2023+thrid part c++ compiler, step by step for windows. It doesn't need to be added into SDK_Document.zip file. It can be just a post and set to top at SDK dev forum.

Let's not talk too much about this here. This topic should be in SDK dev forum. But I think you get the point. 

This year marks my 41st year of programming, a lot of which was in C++, yet it took me nearly a week to get the SDK installed, setup and working about 4-5 years ago. I managed to figure out most (not all) of what I needed and it was such a painful process I just stick to DAZ Script now, which gives me Mac compatibility for "free". Anything I can't do in DAZ Script is just not worth doing and there are at least a dozen great ideas on the shelf because of this.

There has been an update to use CMake, probably after you went through that. It does, I am told, include step-by-step instructions though I have never managed to get around to installing a working development environment.

memcneil70 said:

Is there a way to fix the sort order again? I tried sort by order date on the 'Ready to Download' tab and it defaults to '# A - Z order still. So if I buy an older product, I have to search for it by name. And there have been times I have missed one or two.

I don't curremtly have many files there to se the results, but with Show hidden enabled it seems to be sorting correctly for me. Is the label on the sort order button alsos ticking, or is it chnaging but not being reflected in the list?

And is there anyway to adjust the color scheme? The light grey and pale grey background is hard on my old eyes. I would like to be able to go for a darker grey and medium grey for example.

This first experience has been on my DIM on a Win 10 laptop where I don't keep zip files. After I see what happens on the desktop Win 10 and MacBookPro M1 where I do keep files on external hard drives, I will note how long it takes. The MBP has been well over two hours since the last OS update.

To see the full screen, I spread the size of the frame out until I could read the names of the products. Not a problem with large screens but may be an issue is someone has a small screen footprint.

Thanks for the update

Mary

Edit to add, just found the little arrow on the left side to close up the launchable products. Something I wouldn't use.

Yay it finally is able to attach an image!!!

Made this for another forum for Llolas ROTM!!

Is there a way to fix the sort order again? I tried sort by order date on the 'Ready to Download' tab and it defaults to '# A - Z order still. So if I buy an older product, I have to search for it by name. And there have been times I have missed one or two.

And is there anyway to adjust the color scheme? The light grey and pale grey background is hard on my old eyes. I would like to be able to go for a darker grey and medium grey for example.

This first experience has been on my DIM on a Win 10 laptop where I don't keep zip files. After I see what happens on the desktop Win 10 and MacBookPro M1 where I do keep files on external hard drives, I will note how long it takes. The MBP has been well over two hours since the last OS update.

To see the full screen, I spread the size of the frame out until I could read the names of the products. Not a problem with large screens but may be an issue is someone has a small screen footprint.

Thanks for the update

Mary

Edit to add, just found the little arrow on the left side to close up the launchable products. Something I wouldn't use.

cridgit said:

butaixianran said:

The bad part of Daz's C++ plugin's document is not the API part, is the quick start part. 

The SDK document is very old and asks us to install very old version of Visual Studio.  Many developers won't do that, they just want to use latest development tools. If a developer's other projects can work with latest dev tools, they won't install an old version just for Daz. So, if Daz' SDK can not work with VS 2022 and no document about how to make it work, they just left.

As I searched in forum, SDK doesn't work with VS 2019 or later any more. And no tutorial about how to make it work with VS 2022. I won't install VS 2010 just for Daz, so like other developers, I just left.

Since VS 2022 won't work, I think Daz need a new quick start document for SDK dev, based on VS Code 2023+thrid part c++ compiler, step by step for windows. It doesn't need to be added into SDK_Document.zip file. It can be just a post and set to top at SDK dev forum.

Let's not talk too much about this here. This topic should be in SDK dev forum. But I think you get the point. 

This year marks my 41st year of programming, a lot of which was in C++, yet it took me nearly a week to get the SDK installed, setup and working about 4-5 years ago. I managed to figure out most (not all) of what I needed and it was such a painful process I just stick to DAZ Script now, which gives me Mac compatibility for "free". Anything I can't do in DAZ Script is just not worth doing and there are at least a dozen great ideas on the shelf because of this.

Wow, 41 years!   I just started to learn DAZ script. It seems it's a right choice and direction as per what you mentioned above!  I ever learnt Pascal in college many many years ago but have nearly zero knowledge & exp. in C++. The only development software I ever used is Delphi.

I wrote a DAZ script several months ago by self learning, to switch cameras in Viewport with a shortcut key which is very useful though the coding might be poor

butaixianran said:

The bad part of Daz's C++ plugin's document is not the API part, is the quick start part. 

The SDK document is very old and asks us to install very old version of Visual Studio.  Many developers won't do that, they just want to use latest development tools. If a developer's other projects can work with latest dev tools, they won't install an old version just for Daz. So, if Daz' SDK can not work with VS 2022 and no document about how to make it work, they just left.

As I searched in forum, SDK doesn't work with VS 2019 or later any more. And no tutorial about how to make it work with VS 2022. I won't install VS 2010 just for Daz, so like other developers, I just left.

Since VS 2022 won't work, I think Daz need a new quick start document for SDK dev, based on VS Code 2023+thrid part c++ compiler, step by step for windows. It doesn't need to be added into SDK_Document.zip file. It can be just a post and set to top at SDK dev forum.

Let's not talk too much about this here. This topic should be in SDK dev forum. But I think you get the point. 

This year marks my 41st year of programming, a lot of which was in C++, yet it took me nearly a week to get the SDK installed, setup and working about 4-5 years ago. I managed to figure out most (not all) of what I needed and it was such a painful process I just stick to DAZ Script now, which gives me Mac compatibility for "free". Anything I can't do in DAZ Script is just not worth doing and there are at least a dozen great ideas on the shelf because of this.

 I did have my avatar at one time as a goat and my name as a goat & then I found out what in the last 10 years or so gamers and atheletics started using the word goat for, G.O.A.T. (greatest of all time) and I just had to role my eyes. I did keep goat as my forum name at one place elsewhere though, in spite of my embarrassment at having so naively chose that moniker. Goat used to mean something completely different and comical in slang. I can fend off the harassment keeping it brings, I've been doing that since I was 5; when a goat chased me from one side of a swinging bridge to the other to avoid it's horns. 

I consider this thread "solved", I turned off SLI, had to shut down a lot of apps running in the background to do it.  (including Windows Search which took me forever to find.)

Then my monitors blinked off and I hit enter while it was dark and Nvidia uninstalled SLI.

Now I can load in Iray and render the Viking Camp (high res version) with my GPUs!

So YES it is worth having NVLINK!

With SLI on, NVLINK does not function properly.

It sends texture data to the wrong GPU and textures do not render right at all!

Before I turned off SLI I could not even get the Viking cam to show in Iray without deleting half of the items in the scene.

And when I added a number 2 to the NVLINK peer group size in the render advanced settings my textures in my scene would go all wonky.

If you have 2 X 3090s connected by NVLINK turn off SLI... And Daz works great! Huge gain!

Add a number 2 to the NVLINK peer group size in the render advanced settings! And you are good to go!

The bad part of Daz's C++ plugin's document is not the API part, is the quick start part. 

The SDK document is very old and asks us to install very old version of Visual Studio.  Many developers won't do that, they just want to use latest development tools. If a developer's other projects can work with latest dev tools, they won't install an old version just for Daz. So, if Daz' SDK can not work with VS 2022 and no document about how to make it work, they just left.

As I searched in forum, SDK doesn't work with VS 2019 or later any more. And no tutorial about how to make it work with VS 2022. I won't install VS 2010 just for Daz, so like other developers, I just left.

Since VS 2022 won't work, I think Daz need a new quick start document for SDK dev, based on VS Code 2023+thrid part c++ compiler, step by step for windows. It doesn't need to be added into SDK_Document.zip file. It can be just a post and set to top at SDK dev forum.

Let's not talk too much about this here. This topic should be in SDK dev forum. But I think you get the point. 

Timotheus said:

richardandtracy said:

If you look in the freebie forum you'll see there is a competition to create renders with freebie items in them, limiting the content to 5 paid for items. Part of the rules of the competition is that you must list & provide links to every freebie & paid for item. I have found that it is a hugely onerous requirement, and never takes less than twice the time necessary to create the image just to compile the list. I have to confess that it's so onerous that I have not taken part in many recent competitions as the fun is drained out of it by the effort needed to comply.

Can I suggest you take part in one of the image competitions to experience what I mean. It is fun to create the image, but listing everything's source really isn't.

So.. Nice idea. In reality, forget it.

Regards,

Richard.

I understand your perspective for the case you describe, but I don't think that absolves PAs from such a simple responsibility in the case of selling their products. But then again, I feel the same about gallery images, too. Of course, it should also be very easy to do for PAs in the store system, and I don't know that it is.

Tim

What "responsibility"? You can want that information all you want, but that doesn't mean that PAs are responsible for providing it. As I always say in these discussions, the one and only job of a promo render is to advertise the product being sold. I certainly encourage PAs to list products used, but utterly reject the idea that they have a responsibility to do so, much less that they should be required to (not that you're suggesting it, but others have).

butaixianran said:

Ok, I'm glad people still care. And here is some information about XPBD.

First of all, it's actually not a new thing. Open source XPBD projects have been build at least 6 years before. And Blender community has discussed XPBD since 2018. 

There are tons of open source XPBD projects on github with MIT license. Daz team should check them. This system can be done as a Blender addon or a Daz C++ plugin. 

Above posts talk about Daz's script document. Actually, that document is not that bad. API is all there, with some important examples. Also this forum keeps replying all those questions about writing a script. The bad part is Daz's C++ plugin's document. That's why there are so many Daz scripts, but barely any C++ plugins. 

But the scripting is much the same API as the plugins, with looser constraints on things like typing of course and with soem features lacking. But the script docs and samples should provide a solid grounding for SDK development, and judging by the change log both are documented together (though teh need to maintain API compatibility means we don't yet have an SDK with the new features available in script, adn so don't get the updated documents either).

I'm pretty sure we have more scripts than plug-ins because they are easier - no extra tools needed, no worries about linking the right libraries, easily iterated, cross-patform and so on. I've certainly written and released far more scripts for DS than I have applications, and all of those that saw the light of day were written in a compiled Basic.

About how XPBD works, it treats mesh as a collection of particles. All of its parameters are about particles.

For example, the distance of particles. Less distance means more particle on a mesh and simulation will be slower, but with better result. The same about gravity. A part with more particles on a mesh, will be heavier than a part with less particles on that mesh. So, it's not just as simple as build a plugin. People need to think simulation in another way and have meshes designed for XPBD. Luckily, most clothes are done with MD, which is already based on XPBD. So, clothes won't be an issue. But other meshes, may need to adjust for XPBD.

Like I mentioned, XPBD is a whole new generation.