mcorr said:

Not sure I need the headache (without any form of compensation) to beta test a -- what is already billed as -- buggy pre-beta for the M1. Pass on that.

A more accurate description would be a pre-beta for both Windows and Macs for DAZ Studio 5 while also adding a feature or two for the Mac users to test, features that  Windows users have had for months. Personally, if I were you or another Windows user I'd avoid it like the plague. A beta version, with new featuers, maybe, but a pre-bata? Yuk. Heck, if they weren't giving Mac users a version of Filament to test for the first time, I'd stay away from this one myself. "Headache" is too weak a word.

If it runs under Big Sur, it should automatically run on an m1 chip using Roetta2, like almost all other software has. The ability to run under Big Sur is the more important part for Mac users, eventual m1-native support is the icing on the cake... eventually.

Both Windows and Mac users are going to lose most of the same things like plug-ins, scripts and who knows what else. The only reason a user should be interested in working with something this early in the develpment cycle would be to test something new, which for Mac users and me is Filament on a Mac. I never have enough free time to help with beta testing but in this instance, I've already set aside a computer solely to test it.

-- Walt Sterdan

Panzer Emerald said:

Well hallelujah praise the Lord!

At this point, I'll take what I can get. For all my griping, grousing, and general sourness... thank you. Thank you for finally listen to us Mac users.

I think they've always been listening to Mac users; if you look at the fact that we're getting a pre-beta, not a beta, it helps underscore just how incredibly huge an undertaking updating to DAZ 5 is, and how we'll have the pre-beta (hopefully) in the next month but probably won't see final release of D|S 5 until close to year-end. Even so, giving us just that bit of news to keep Mac users hopeful has already resulted in over 10 forum pages of questions, speculaton, arguements about speculation and so on... that tells me why they're so reluctant to offer us a status report without having something more concrete to report. 

 I've been both vocal and even a little testy with poor Richard at times from the frustration of pausing projects plans for lack of a status update. Like you, I'm very happy to have a ballpark ETA for even the pre-beta. I never normally touch Beta releases as I just don't have enough spare time to help; in this case, I've already set up a machine specifically to start testing the Mac versiion of D|S with Filament as soon as I can.

-- Walt Sterdan

hacsart said:

heh - i remember paper tape from those days - still have a bit saved... the old days were fun! (although not always ata the time..) First system I was alowed to run- IBM 360/40 (Although we had a 1401, I never got to seriously work with it..)

Artini said:

bytescapes said:

Artini said:

If Daz Studio will run natively on Apple M1 or higher CPUs, than I will be considering getting Apple computer (first time in my life).

Just to see rendering on Apple M1 GPU is worth to wait for...

 You might not see dramatic rendering improvements on M1 (although I'd bet the interface will be a bit zippier).

Apple and Nvidia have fallen out, so you won't find any Nvidia GPUs in future Macs, or even OS support for the Nvidia GPUs found in older Macs. So for Iray renders, you'll be forced to fall back on CPU rendering.

When Iray uses the CPU to render, it seems to create some of the code it needs to do the render 'on the fly'. The code is designed to run on processors using the x86 architecture (i.e. Intel and AMD chips).

To run x86 code on Apple Silicon such as the M1, the code has to be translated into instructions that the Apple chip can execute. Wherever possible, Apple pre-translates the code when the application is first installed. But because the Iray rendering code is generated dynamically when you start the render, they can't do that. Instead, Apple's Rosetta 2 translation engine has to translate it all then and there. I'm simplifying a bit, but the upshot is that Apple has to do a bunch of work to get the rendering code into a form that their chips can work with. That work takes time and the end result is that everything they have to do slows down the rendering process (and CPU rendering is already much slower than GPU rendering).

It's possible that the Apple chips (the M1, and its likely successors the M1X and M2) have so much power to spare that they can do all this extra work and still beat the performance of the old Intel chips. But I think it's more likely that rendering on Apple Silicon will work out a little slower than rendering on an Intel or AMD CPU, and certainly slower than rendering on an Nvidia GPU. Another factor is that the Apple M1 systems we've seen so far have limited memory -- 8GB or 16GB -- which will make things still slower when handling larger scenes.

Note that this all applies to Iray renders. I don't know if 3Delight will be optimized for Apple Silicon, but I think that Octane already has been, and I believe that Filament could be. And Blender has an Apple Silicon version, although I don't know if their renderers have yet been optimized for Apple chips. So anything other than Iray could eventually enjoy some remarkable speed-ups on Apple Silicon (especially if the renderer can make use of Apple's own GPUs rather than the CPU). But Iray probably won't.

I may be very wrong about this, but this is how things stand now, as I understand them.

You have not made a tests with Apple M1 hardware, apparently.

From my own experiments I see 5 to 50 times speed increase in 3D graphics applications on MacBook Pro 13 inches with Apple M1 hardware

while comparing with older Macs, even with Nvidia graphics card.

I know, that iray does not support Apple M1 natively yet, but hopefully Apple will find another solution.

Right now I am amazed by Apple M1 performance and believe me I have started my journey with the computers

like mainframes that were using paper tape as a program and data input, Timex TS1000 with 8 bit CPU and 2 KB RAM

and continue with all possible hardware including the latest ones.

Nice memories. During my university studies, I have used punched paper cards to deliver program and data to the computer centre

and got results just after a week of time. Any error and another week of waiting to get another error report or results.

Imagine wait for the render 1 week and then discover, that some part of the scene you want in different place,

and since you cannot see the preview of results, you need to punch cards with different contents and process them again.

At least the corrections to the data was quite fast, if you only need to replace a couple of the cards.

Each card could carry one line of the data or program (in Fortran in my case).

Imago said:

Kainjy said:

Ad esempio online c'è il manuale di Filament, noterai che ci sono funzioni che in DAZ Filament non ha... magari con la versione 5 di DAZ le implementeranno.

La cosa inizia ad essere inquietante, ragazzo... Io dico che la DAZ deve implementare meglio Filament e che ci sono un sacco di funzioni che DAZ Studio non usa ancora... e tu mi dici che mi sbaglio ribadendo che DAZ dovrebbe implementare meglio Filament e che ci sono un sacco di funzioni inutilizzate? 

Vediamo se con DAZ 5 si vede qualcosa di buono come migliori implementazioni e fix dei bugs.

Tranquillo, forse non mi sono spiegato io... Filament lo sviluppa Google per cui è Google ad aggiungere funzioni in base ai soldi, al tempo e all'interesse della gente. DAZ crea solo il plugin di collegamento con il quale manda la mesh e i settaggi al render engine che poi a sua volta rinivia il render a DAZ Studio e si occupa di impacchettare tutto per noi utenti (che così abbiamo tutto incluso in un'unico pacchetto).
Per cui il motore di rendering è una scatola chiusa che DAZ ha scelto di usare (come tutti i motori di rendering) ed implementare inglobandola.

Eventuali problemi di rendering possono essere causati da 2 fasi fondamentali:

• il plugin (DAZ) non ha esportato bene la mesh o qualche settaggio (perchè magari c'è un bug che distorce la mesh oppure c'è un settaggio che viene convertito male)
• Il render engine (Filament) ha un bug interno che ti renderizza male la scena

La stessa cosa vale per Iray...per cui se un'ombra ti appare male bisogna vedere chi dei 2 ha sbagliato, potrebbe essere stato DAZ o Iray stesso. Nel caso di Filament è un limite dell'engine che per generare ombre gli oggetti devono essere nel cono della luce e devono essere attive le ombre nei parametri della luce (cosa che invece Iray non ha bisogno perchè calcola le ombre in automatico e quel parametro lo ignora proprio, mentre invece serve se usi 3DeLight). Per cui DAZ non centra nulla per questa volta.

 

Il problema dell'implementazione di Filament è che DAZ sta indietro di qualche versione rispetto a quella ufficialmente lasciata da Google. Non so se per motivi di tempo/soldi o forse (penso la più probabile) proprio di funzionamento: infatti se viene rilasciato un nuovo Filament molte funzioni aggiunte spesso non vanno o potrebbero essere fonti di bug per Filament stesso.

Ad esempio con Vray (motore di rendering top di gamma) quando è uscito il 2.0 (che è stato un grosso salto) ogni mese c'era un update perchè dovevano correggere bug che sono venuti fuori solo quando lo hanno pubblicato o magari dovevano mettere funzioni che gli utenti chiedevano e la software house non ci aveva pensato. Essendo però un motore esterno potevano pubblicare aggiornamenti come volevano perchè non toccavano il codice di 3DS max (della Autodesk) e il plugin di comunicazione lo gestivano loro stessi. Agli utenti arrivano aggiornamenti di continuo.

Non penso che DAZ voglia lasciare aggiornamenti di continuo solo perchè cambiano 2 funzioni che poi vanno male e dopo altri 15 giorni Google rilascia una nuova patch (che DAZ deve così rigirare poi a noi.. diventa un circolo vizioso). Tra l'altro il motore è open source e lo trovi su Github (https://github.com/google/filament) per cui ci possono lavorare anche programmatori esterni di passaggio.

Per cui io non vedo problemi nell'implementazione (che funziona e non mi pare ci siano grossi bug). Non è che aggiornando il motore ottieni risultati favolosi, Filament funziona in un certo modo e le sue funzioni di base sono quelle e non è pensato per Hardware performanti. Essendo open e in sviluppo forse non vogliono essere costretti a rilasciare molti aggiornamenti (perchè il motore non è esterno ma incluso insieme a DAZ Studio) per aggiungere cose che comunque non apportano grossi miglioramenti.

PS ricordati anche che ora come ora i materiali Iray sono compatibili (la conversione è automatica) con Filament perchè si basano su modelli PBR.. se aggiungessero shader solo per Filament avremmo 3 diversi tipi di materiali: Iray, 3DeLight e Filament. Se poi metti anche luci supportate solo per Filament e altre funzioni (come magari Decal solo per Filament)...  Immagina che casino !!!  Intanto aspettiamo la 5.0 e vediamo

 

Crios said:

Ragazzi, posso uscire un po' dal discorso del Filament, anche se mi interesserebbe molto usarlo al meglio. Avete mai visto Belve? Il programma di RAI Due. Avete mai visto la sigla? Ma neanche 20 anni fa facevano un animazione così schifosa. Se mi davano 10 € col DAZ gliela facevo meglio, e io non faccio animazioni.

Dici? Semmai è bruttarella la pantera, però in generale tutta la scena non è male. Se chiamano te la prossima volta magari fatti dare più di 10 € 

wsterdan said:

It is possible to create a Metal-based rendering engine, though, where GPUs could be used both by Apple and Windows machines, but that means looking at still another texturing system; while it has a few nice ray-tracing features (like motion blur).

-- Walt Sterdan

Not just possible. It is already here: https://www.amd.com/en/technologies/radeon-prorender
ProRender 2.0 is free, open-source, supports Vulkan, OpenCL and Metal.
There are also three Filament-like modes. One is for pure reasterization, which is good for viewport rendering, one with baised GI on rasterization, and some ray traced effects (reflection, refraction, ambient occlusion, etc.), and one ray-traced mode, where the base rendering is still rasterization, but ray tracing is applied to achieve biased photorealistic rendering.

Ragazzi, posso uscire un po' dal discorso del Filament, anche se mi interesserebbe molto usarlo al meglio. Avete mai visto Belve? Il programma di RAI Due. Avete mai visto la sigla? Ma neanche 20 anni fa facevano un animazione così schifosa. Se mi davano 10 € col DAZ gliela facevo meglio, e io non faccio animazioni.

Kainjy said:

Ad esempio online c'è il manuale di Filament, noterai che ci sono funzioni che in DAZ Filament non ha... magari con la versione 5 di DAZ le implementeranno.

La cosa inizia ad essere inquietante, ragazzo... Io dico che la DAZ deve implementare meglio Filament e che ci sono un sacco di funzioni che DAZ Studio non usa ancora... e tu mi dici che mi sbaglio ribadendo che DAZ dovrebbe implementare meglio Filament e che ci sono un sacco di funzioni inutilizzate? 

Vediamo se con DAZ 5 si vede qualcosa di buono come migliori implementazioni e fix dei bugs.

@jonathanlivingston

Il Filament di DAZ è limitato in moltissimi settaggi, guardati il video di WP Guru https://youtu.be/88LuOEpYuSE che è una buonissima introduzione.. Oltre al limite delle luci, hai anche problemi ai riflessi e alle trasparenze (capelli con mesh a card non li mettere, cerca di usare capelli Fibermesh) e molti effetti (quelli volumetrici come SSS) non sono supportati perchè il motore è stato pensato inizialmente per girare su dispositivi mobile e/o browser di una pagina internet.

Sì sì, ero proprio partito da quello: bellissimo e fatto bene, come tutti i suoi. Poi parlato in un inglese chiarissimo e non velocissimo, il che non guasta mai ;)

Posso fare una domanda stupidissima, ma che mi tornerebbe utile? Come faccio a far comparire un oggetto nel punto preciso della scena in cui sto lavorando? Se aggiungo un prop, esso andrà alla radice, ma se io sto lavorando a 50 metri di distanza, tutte le volte devo tornare indietro e portarlo sul posto a mano. C'è un sistema per semplificare il tutto?

 

Molte grazie

@Imago

Non so se la gestione della memoria è un problema di DAZ quando esporta verso Iray o di Iray stesso che immagazzina male i dati sulla RAM/VRAM (e anche HD)... purtroppo di tratta di roba di codice da programmatore.

Stesso discorso per le ombre.. in teoria DAZ esporta solo informazioni (mesh e settaggi dei materiali/luci) e poi è Iray che riassembla tutto e inizia a simulare la scena 3D (e a calcolare le ombre) .. non so per cui quanto è colpa di DAZ e quanta di Iray.

Per gli emissivi (ma anche gli altri materiali) ricordati che Iray richiede di programmare/creare gli shader con lo Shader Mixer. L'Iray Uber Shader è uno shader creato da un programmatore che ha voluto inserire tutti gli effetti possibili (volumetrici, di superficie, di riflessione/rigrazione, emissivi, ecc..) in un'unico materiale per semplificare la vita a molti. Nulla ti vieta di crearti il tuo materiale personalizzato (anzi è consigliato da Nvidia stessa) che sicuramente è più leggero dell'Uber (perchè appunto non esegue calcoli di effetti che a te non servono e può essere calibrato come meglio credi). 

La DAZ ha sicurmente colpa di non usare l'ultima versione di Iray (ma anche Filament) poichè questi motori vengono aggiornati di continuo e ciò significa, oltre a dover distribuire un aggiornamento periodico a tutti i propri utenti solo perchè cambia il solo motore di rendering, anche dover mettere mano ai plugin di comunicazione/esportazione e all'interfaccia del programma per aggiungere le nuove funzioni (che poi non è detto funzionino bene o che non creino altri problemi).

Ad esempio online c'è il manuale di Filament, noterai che ci sono funzioni che in DAZ Filament non ha... magari con la versione 5 di DAZ le implementeranno.

PS ma qualcuno usa Octane ? Il motore è gratis con DAZ ma non ho ancora avuto modo di provarlo.. potrebbe essere una valida alternativa ?  

 

@jonathanlivingston

Il Filament di DAZ è limitato in moltissimi settaggi, guardati il video di WP Guru https://youtu.be/88LuOEpYuSE che è una buonissima introduzione.. Oltre al limite delle luci, hai anche problemi ai riflessi e alle trasparenze (capelli con mesh a card non li mettere, cerca di usare capelli Fibermesh) e molti effetti (quelli volumetrici come SSS) non sono supportati perchè il motore è stato pensato inizialmente per girare su dispositivi mobile e/o browser di una pagina internet.

Kainjy said:

 l'unica cosa su cui la Daz può lavorare è l'interfaccia e l'implementazione con Daz Studio.

E io che cosa ho detto, scusa?  ┻━┻ ︵ ＼( °□° )／ ︵ ┻━┻

Sono quelli della DAZ3D che devono correggere il sistema di gestione della memoria per non spezzare le ombre, che devono implementare le ombre su tutte le luci, implementare meglio gli emissivi, raddrizzare il sistema del gamma, migliorare il sistema di buffering per il Dome e correggere il layering delle trasparenze.

Filament ha già un mucchio di funzioni inutilizzate da DAZ Studio al momento.

@Imago Purtroppo Filament è di Google.. Per cui è Google che deve aggiornare il motore (come Iray che è di Nvidia) l'unica cosa su cui la Daz può lavorare è l'interfaccia e l'implementazione con Daz Studio. Non possono aggiungere funzioni che le software house proprietarie non hanno già fatto. Ps Iray lo usa ancora anche Iclone/Character Creator

heh - i remember paper tape from those days - still have a bit saved... the old days were fun! (although not always ata the time..) First system I was alowed to run- IBM 360/40 (Although we had a 1401, I never got to seriously work with it..)

Artini said:

bytescapes said:

Artini said:

If Daz Studio will run natively on Apple M1 or higher CPUs, than I will be considering getting Apple computer (first time in my life).

Just to see rendering on Apple M1 GPU is worth to wait for...

 You might not see dramatic rendering improvements on M1 (although I'd bet the interface will be a bit zippier).

Apple and Nvidia have fallen out, so you won't find any Nvidia GPUs in future Macs, or even OS support for the Nvidia GPUs found in older Macs. So for Iray renders, you'll be forced to fall back on CPU rendering.

When Iray uses the CPU to render, it seems to create some of the code it needs to do the render 'on the fly'. The code is designed to run on processors using the x86 architecture (i.e. Intel and AMD chips).

To run x86 code on Apple Silicon such as the M1, the code has to be translated into instructions that the Apple chip can execute. Wherever possible, Apple pre-translates the code when the application is first installed. But because the Iray rendering code is generated dynamically when you start the render, they can't do that. Instead, Apple's Rosetta 2 translation engine has to translate it all then and there. I'm simplifying a bit, but the upshot is that Apple has to do a bunch of work to get the rendering code into a form that their chips can work with. That work takes time and the end result is that everything they have to do slows down the rendering process (and CPU rendering is already much slower than GPU rendering).

It's possible that the Apple chips (the M1, and its likely successors the M1X and M2) have so much power to spare that they can do all this extra work and still beat the performance of the old Intel chips. But I think it's more likely that rendering on Apple Silicon will work out a little slower than rendering on an Intel or AMD CPU, and certainly slower than rendering on an Nvidia GPU. Another factor is that the Apple M1 systems we've seen so far have limited memory -- 8GB or 16GB -- which will make things still slower when handling larger scenes.

Note that this all applies to Iray renders. I don't know if 3Delight will be optimized for Apple Silicon, but I think that Octane already has been, and I believe that Filament could be. And Blender has an Apple Silicon version, although I don't know if their renderers have yet been optimized for Apple chips. So anything other than Iray could eventually enjoy some remarkable speed-ups on Apple Silicon (especially if the renderer can make use of Apple's own GPUs rather than the CPU). But Iray probably won't.

I may be very wrong about this, but this is how things stand now, as I understand them.

You have not made a tests with Apple M1 hardware, apparently.

From my own experiments I see 5 to 50 times speed increase in 3D graphics applications on MacBook Pro 13 inches with Apple M1 hardware

while comparing with older Macs, even with Nvidia graphics card.

I know, that iray does not support Apple M1 natively yet, but hopefully Apple will find another solution.

Right now I am amazed by Apple M1 performance and believe me I have started my journey with the computers

like mainframes that were using paper tape as a program and data input, Timex TS1000 with 8 bit CPU and 2 KB RAM

and continue with all possible hardware including the latest ones.

Ho una domanda base da fare su filament: Come mai non vedo gli effetti luce in diretta? Mi spiego. Ho una scena, scelgo filament, metto su dome and scene e mi aspetterei di vedere l'effetto che le spotlight fanno in diretta sulla mia scena. Invece nulla :( Soltanto qualche volta vedo qualche timido effetto nell'aux viewport, in quello normale nulla. In più ho notato che a volte non vedo il mio oggetto, ma una roba strana tipo un'ombra...

Dove sbaglio? Vorrei poter usare filament nel modo giusto. Grazie.

Mustakettu85 said:

j cade said:

Iray 2021 has support for heterogenous volumes

Even a very basic 2D sort of opacity masking could add some interesting visual detail.

Tirick said:

 Not currently, plug in opacity and the volume will disapear entirely

 

Tirick said:

Volumetric clouds and smoke would be really sweet.

The funniest thing about Fluidos is that it uses OpenVDB internally... so it could give us amazing smoke sim results out of the box, without remeshing etc. But I'm not sure if Iray or Filament can handle OpenVDB natively - yet - and while 3Delight standalone has been able to for quite a while, its OpenVDB lib doesn't really work with the version built into DS because of certain tech limitations. So Fluidos has to use all those workarounds.

Iray reading openVDB support is likewise a part of iray 2021, whether that gets integrated ino DS still remains to be answered but until then its not even theoretically possible

Periastron said:

wsterdan said:

Periastron said:

Has anyone actually got DS running under Wine in a stable fashion?  I couldn't even keep it from exploding under VMware Fusion.

 Are you talking about VM Fusion on an m1 chip and/or Big Sur?

-- Walt Sterdan

Big Sur, VMware Fusion 12, but an Intel box:  8-core i7, four cores and 8 GB RAM assigned to the VM.  (The iMac has 40 GB; it's a 2020 model with the AMD Radeon Pro 5700 XT 16 GB.)  It would basically segfault any time I tried an iRay render.

Ah, I see, I see; I use  VM Fusion to run Windows D|S and Filament without issue, but I don't think I've attempted an iRay render. I'll test it tonight, but I wonder if you'd have any better luck if you temporarily boosted the RAM allocated to Parallels. I'll test VM Fusion with only 8 GB first and I'll let you know how it goes.

-- Walt Sterdan 

j cade said:

Iray 2021 has support for heterogenous volumes

Even a very basic 2D sort of opacity masking could add some interesting visual detail.

Tirick said:

Volumetric clouds and smoke would be really sweet.

The funniest thing about Fluidos is that it uses OpenVDB internally... so it could give us amazing smoke sim results out of the box, without remeshing etc. But I'm not sure if Iray or Filament can handle OpenVDB natively - yet - and while 3Delight standalone has been able to for quite a while, its OpenVDB lib doesn't really work with the version built into DS because of certain tech limitations. So Fluidos has to use all those workarounds.

Starkdog said:

Hello Don,

x86 is a type of Intel chip that were in Macs until recently.  Apple now has their M1 processer chip, and they are moving the Apple platform back to their own chip.

Filament is a "lighter-weight" PBR(Physically-Based Renderer) rendering engine.  I really haven't looked into it much, as I mostly use Iray.

Qt libraries are a set of "building blocks" and compiler used to build applications in C++.  DAZ Studio is built in C++, and thus needs a way to compile all the different functions and subroutines into one cohesive program.  Qt is one such platform to compile C++ for both PC, MAC, and I also believe Linux as well.

Thanx for the info, Starkdog.

wsterdan said:

nonesuch00 said:

TBorNot said:

I wouldn't have any problem paying the same as Poser for a DAZ3D native M1 version that used Metal directly.

Why? Metal doesn't affect the performance of useful applications

 Metal is the graphics language used on the M series of Apple processors. Metal is to Apple as iRay is to NVIDIA. There are several graphics libraries available that support both Metal and various others, making transportability of code between computers easy.

That would be Filament using Metal as it's backend on Apple products because iRay would work on modern Apple products but can't when nVidia video card hardware is absent on modern Apple hardware that cannot be upgraded to use new nVidia hardware. You have to consider what would nVidia's motive be in porting their free software solution to Apple hardware that they only wrote in order to sell nVidia hardware but can't sell nVidia hardware on Apple platforms because those platforms don't include nVidia hardware or the capability to upgrade to use nVidia hardware. If they can't earn their bread on Apple platforms they shouldn't exert one iota of effort on Apple platforms. Customers that want to use nVidia software should choose platforms that nVidia software supports. One shouldn't hold their breath expecting Apple & nVidia to make up. Both know their core customers aren't going to dump one for the other because of the impass between Apple & nVidia. If you have enough money to burn you can buy single use case hardware for both Apple & nVidia but you'll have at least 2 computers to do that.

Just to clarify, iRay does work without issue on machines without iRay GPUs, just very slowly compared to machines with iRay GPUs... probably about as fast as those NVidia machines that are occasionally forced to drop back to CPU rendering due to lack of sufficioent VRAM.

-- Walt Sterdan 

I started out rendering on a 3.5ghz i5.  Most of the scenes I did took at least 12 hours to render.  Then I switched to a dedicated render PC with a 970 GPU.  The render times dropped to just over an hour!

Cheers,

Alex. 

nonesuch00 said:

TBorNot said:

I wouldn't have any problem paying the same as Poser for a DAZ3D native M1 version that used Metal directly.

Why? Metal doesn't affect the performance of useful applications

 Metal is the graphics language used on the M series of Apple processors. Metal is to Apple as iRay is to NVIDIA. There are several graphics libraries available that support both Metal and various others, making transportability of code between computers easy.

That would be Filament using Metal as it's backend on Apple products because iRay would work on modern Apple products but can't when nVidia video card hardware is absent on modern Apple hardware that cannot be upgraded to use new nVidia hardware. You have to consider what would nVidia's motive be in porting their free software solution to Apple hardware that they only wrote in order to sell nVidia hardware but can't sell nVidia hardware on Apple platforms because those platforms don't include nVidia hardware or the capability to upgrade to use nVidia hardware. If they can't earn their bread on Apple platforms they shouldn't exert one iota of effort on Apple platforms. Customers that want to use nVidia software should choose platforms that nVidia software supports. One shouldn't hold their breath expecting Apple & nVidia to make up. Both know their core customers aren't going to dump one for the other because of the impass between Apple & nVidia. If you have enough money to burn you can buy single use case hardware for both Apple & nVidia but you'll have at least 2 computers to do that.

Just to clarify, iRay does work without issue on machines without iRay GPUs, just very slowly compared to machines with iRay GPUs... probably about as fast as those NVidia machines that are occasionally forced to drop back to CPU rendering due to lack of sufficioent VRAM.

-- Walt Sterdan