Urgh.
Not having any problems with the Beta yet... because I can't install it!
Downloaded the two files to a USB drive, transferred them to my 3D computer - Install Manager Downloads folder.
Fired up DIM, it showed them as "ready to install".Clicked "Install".
Public Beta Content 1 installed as 55 bytes.
Scene Builder failed to install, Installed path for "DAZ Studio 4.x Public Build" is not defined.
Went to "settings-applications-add application" and there's no public build listed to add.
Can someone please help me get this on my computer? I have the latest version of 4.9 installed, although I mostly use 4.8 still. Thank you.
Public Beta Content 1 DS installed size is 55 Bytes according to DIM. It seems to be a singe "placeholder" text file. Scene Builder is just a single json file.
In DIM, you should have DAZ Studio 4.9 (Win 64-Bit) Public Build +Beta+. That is the 512.1 MB application installer. You would need to copy that to your other computer also.
In DIM I have a path configured for DAZ Studio 4.x Public Build (64-bit), but you are right that there is no such thing in the Applications dropdown selection now in DIM version 1.1.0.64. I wonder if that is a DIM bug? I suggest that you submit a help request about that apparent DIM issue.
Urgh.
Not having any problems with the Beta yet... because I can't install it!
Downloaded the two files to a USB drive, transferred them to my 3D computer - Install Manager Downloads folder.
Fired up DIM, it showed them as "ready to install".Clicked "Install".
Public Beta Content 1 installed as 55 bytes.
Scene Builder failed to install, Installed path for "DAZ Studio 4.x Public Build" is not defined.
Went to "settings-applications-add application" and there's no public build listed to add.
Can someone please help me get this on my computer? I have the latest version of 4.9 installed, although I mostly use 4.8 still. Thank you.
Public Beta Content 1 DS installed size is 55 Bytes according to DIM. It seems to be a singe "placeholder" text file. Scene Builder is just a single json file.
In DIM, you should have DAZ Studio 4.9 (Win 64-Bit) Public Build +Beta+. That is the 512.1 MB application installer. You would need to copy that to your other computer also.
In DIM I have a path configured for DAZ Studio 4.x Public Build (64-bit), but you are right that there is no such thing in the Applications dropdown selection now in DIM version 1.1.0.64. I wonder if that is a DIM bug? I suggest that you submit a help request about that apparent DIM issue.
Urgh.
Not having any problems with the Beta yet... because I can't install it!
Downloaded the two files to a USB drive, transferred them to my 3D computer - Install Manager Downloads folder.
Fired up DIM, it showed them as "ready to install".Clicked "Install".
Public Beta Content 1 installed as 55 bytes.
Scene Builder failed to install, Installed path for "DAZ Studio 4.x Public Build" is not defined.
Went to "settings-applications-add application" and there's no public build listed to add.
Can someone please help me get this on my computer? I have the latest version of 4.9 installed, although I mostly use 4.8 still. Thank you.
Public Beta Content 1 DS installed size is 55 Bytes according to DIM. It seems to be a singe "placeholder" text file. Scene Builder is just a single json file.
In DIM, you should have DAZ Studio 4.9 (Win 64-Bit) Public Build +Beta+. That is the 512.1 MB application installer. You would need to copy that to your other computer also.
In DIM I have a path configured for DAZ Studio 4.x Public Build (64-bit), but you are right that there is no such thing in the Applications dropdown selection now in DIM version 1.1.0.64. I wonder if that is a DIM bug? I suggest that you submit a help request about that apparent DIM issue.
We are told this is not a bug but by design.
Well then, how does a person install the Beta with the DIM?
I went through several pages of this but didn't see this issue, so apologies if it's already been discussed. I just installed the beta and it will not render using GPU. If I render with GPU and CPU both ticked, it renders CPU only. I've run GPU shark and I am getting zero cycles and virtually no memory used in the GPU so I'm certain it's not being used.
If I render with GPU ticked and CPU not, it opens a render window and then stops triyng (i.e. instead of cancel the button at the bottom says "close" but there is nothing but the transparant checkerboard. This is with a scene of one light, one plane and one sphere, no textures used so I'm certiain it's not too much to load onto the GPU.
My GPU is a vintage Geoforce 750M, works fine with the current official build. Is there a backwards compatibility issue with the new beta?
Urgh.
Not having any problems with the Beta yet... because I can't install it!
Downloaded the two files to a USB drive, transferred them to my 3D computer - Install Manager Downloads folder.
Fired up DIM, it showed them as "ready to install".Clicked "Install".
Public Beta Content 1 installed as 55 bytes.
Scene Builder failed to install, Installed path for "DAZ Studio 4.x Public Build" is not defined.
Went to "settings-applications-add application" and there's no public build listed to add.
Can someone please help me get this on my computer? I have the latest version of 4.9 installed, although I mostly use 4.8 still. Thank you.
Public Beta Content 1 DS installed size is 55 Bytes according to DIM. It seems to be a singe "placeholder" text file. Scene Builder is just a single json file.
In DIM, you should have DAZ Studio 4.9 (Win 64-Bit) Public Build +Beta+. That is the 512.1 MB application installer. You would need to copy that to your other computer also.
In DIM I have a path configured for DAZ Studio 4.x Public Build (64-bit), but you are right that there is no such thing in the Applications dropdown selection now in DIM version 1.1.0.64. I wonder if that is a DIM bug? I suggest that you submit a help request about that apparent DIM issue.
We are told this is not a bug but by design.
Well then, how does a person install the Beta with the DIM?
When you install the beta DIM creates the path. The problem is trying to install add-ons for the beta before the beta itself has been installed.
I went through several pages of this but didn't see this issue, so apologies if it's already been discussed. I just installed the beta and it will not render using GPU. If I render with GPU and CPU both ticked, it renders CPU only. I've run GPU shark and I am getting zero cycles and virtually no memory used in the GPU so I'm certain it's not being used.
If I render with GPU ticked and CPU not, it opens a render window and then stops triyng (i.e. instead of cancel the button at the bottom says "close" but there is nothing but the transparant checkerboard. This is with a scene of one light, one plane and one sphere, no textures used so I'm certiain it's not too much to load onto the GPU.
My GPU is a vintage Geoforce 750M, works fine with the current official build. Is there a backwards compatibility issue with the new beta?
Urgh.
Not having any problems with the Beta yet... because I can't install it!
Downloaded the two files to a USB drive, transferred them to my 3D computer - Install Manager Downloads folder.
Fired up DIM, it showed them as "ready to install".Clicked "Install".
Public Beta Content 1 installed as 55 bytes.
Scene Builder failed to install, Installed path for "DAZ Studio 4.x Public Build" is not defined.
Went to "settings-applications-add application" and there's no public build listed to add.
Can someone please help me get this on my computer? I have the latest version of 4.9 installed, although I mostly use 4.8 still. Thank you.
Public Beta Content 1 DS installed size is 55 Bytes according to DIM. It seems to be a singe "placeholder" text file. Scene Builder is just a single json file.
In DIM, you should have DAZ Studio 4.9 (Win 64-Bit) Public Build +Beta+. That is the 512.1 MB application installer. You would need to copy that to your other computer also.
In DIM I have a path configured for DAZ Studio 4.x Public Build (64-bit), but you are right that there is no such thing in the Applications dropdown selection now in DIM version 1.1.0.64. I wonder if that is a DIM bug? I suggest that you submit a help request about that apparent DIM issue.
We are told this is not a bug but by design.
Well then, how does a person install the Beta with the DIM?
When you install the beta DIM creates the path. The problem is trying to install add-ons for the beta before the beta itself has been installed.
Oh! Thanks! Maybe it would be good to add that the the FAQ in post 1.
Oh! Thanks! Maybe it would be good to add that the the FAQ in post 1.
An application always needs to be installed first before any add-ons for said application, otherwise it won't know which application it is for and where it is to be installed.
But to download "beta daz studio zip" by DIM, DIM need to keep online,, if it is not online,, I can not download anything through DIM.
if I have two PC, and PC A is for 3d only,, and can not access internet,, but PC B can access internet, but may not work for 3d,
I may try install DIM on both PC , then anyway download beta by DIM with PC B,, then download , daz studio beta.
then copy and paste it to PC A DIM downloaded directory,, may work?
(though at least , PC B need ability to download and install DIM,,,, as private usage,,)
the best way is,, I think simply DAZ offer beta download package,, in user account,, (I do not know, why daz restrict it,,)
Yes, download on PC B and copy the file over to PC A.
And if PC B does not have the same operating system as PC A? My online PC is Linux, and DIM locks up at "Update detected" (update for DIM itself) with "Cannot download update".
But to download "beta daz studio zip" by DIM, DIM need to keep online,, if it is not online,, I can not download anything through DIM.
if I have two PC, and PC A is for 3d only,, and can not access internet,, but PC B can access internet, but may not work for 3d,
I may try install DIM on both PC , then anyway download beta by DIM with PC B,, then download , daz studio beta.
then copy and paste it to PC A DIM downloaded directory,, may work?
(though at least , PC B need ability to download and install DIM,,,, as private usage,,)
the best way is,, I think simply DAZ offer beta download package,, in user account,, (I do not know, why daz restrict it,,)
Yes, download on PC B and copy the file over to PC A.
And if PC B does not have the same operating system as PC A? My online PC is Linux, and DIM locks up at "Update detected" (update for DIM itself) with "Cannot download update".
For Windows, there isn't a separate CUDA driver package, it's in the 'main' driver package. 352 is definitely too old a driver version to have the necessary CUDA updates for the version of Iray in the beta.
Thanks, I updated the driver and it works now. I did a render in the official release of an indoor scene (stopped at 12 mins) and saved it, rendered the same scene in the beta for the same duration to see if there was any improvement. Frankly, the official release version seemed a little cleaner. But it's not that different. I was hoping for some good speed improvement like some reported but doesn't seem in the cards for me. Anyway thanks for the suggestions, glad its working now.
Fresh install of DIM, running in WINE.
Followed instructions on product page. Nothing showed up in DIM.
Got lucky - sort of - DAZ logged me out, product page went from red "purchased" to green "purchase".
Clicked "purchase", logged back in. Completed purchase.
Beta shows up in DIM. Downloads at 1.1mbs to 99%.
Download stops. 0.0mbs.
Download fails.
I give up. Wasn't sure if I wanted 10XX series card anyway, waiting for Studio comparisions with my 980ti.
Might buy another 980ti.
Save the lines above in a script and change the width and height variables to your desired resolution. aWidth and aHeight are used to set the aspect ration, so 1920x1080 should set those to 16 and 9 respectively.
Save the lines above in a script and change the width and height variables to your desired resolution. aWidth and aHeight are used to set the aspect ration, so 1920x1080 should set those to 16 and 9 respectively.
saving this as a script and executing it - it changes to the desired resolution - but only in the viewport .... it still renders only the WHOLE viewport.
I was testing with an old scene and tried to render through the camera I saved month ago.
Save the lines above in a script and change the width and height variables to your desired resolution. aWidth and aHeight are used to set the aspect ration, so 1920x1080 should set those to 16 and 9 respectively.
saving this as a script and executing it - it changes to the desired resolution - but only in the viewport .... it still renders only the WHOLE viewport.
I was testing with an old scene and tried to render through the camera I saved month ago.
I render 4K images so I dont think that will work :( Plus I have no idea how to do what you just said
A lot of supposition and/or outright guessing about the problem going on. Most likely is that there is a "close to edge ndition" that simply wasn't found before the beta was sent out for public testing. This is one of the dangers of having testing done by those overly knowledgeable about the software: familiarity keeps the testers from doing the things that the general userbase does.
Do I have some ideas where the problem likely lies? Yes, but only because I have had a look at some of the stuff from nVidia's release. Am I gonna make guesses at what exactly is occurring? No, because the cause can come from multiple vectors and since I don't know exactly what DS is doing at this point (reverse engineering is against the EULA) I am not confident that my guess would have any validity. I *AM* sure that the Daz Devs are aware of where the problem is and are likely describing it in very non-PC and "not appropriate for work but used anyway" verbage.
What I am saying is that throwing out guesses based on less than scant evidence about the cause is unhelpful and likely to be taken by some as credible. This can cause folks to make decisions unwisely using data that are completely without merit.
My advice is to wait for definitive information from Daz.
Kendall
There has been a similar discussion in a differen thread and I hadn't noticed it had blown up over here, too. Assuming everyone who is crashing is receiving the "ILLEGAL_INSTRUCTION" issue in neuray.dll, one needn't reverse engineer the code to discover what the problem is, the problem is all actually reported there in the crash trace that is provided to help you give the Daz folks some information for them to troubleshoot. Unfortunately, *reading* a crash trace properly can be a little tricky. When I saw it first, I thought "SSE 4.1", because having a background in native development and owning an AMD processor, I've screwed up the compiler flags enough times to build a library that won't execute on my own hardware. SSE 4.1, though, as has been pointed out by a few folks in this forum, is not at fault. The ILLEGAL_INSTRUCTION exception is usually provided as a hex code (thanks, Daz, for not doing that!), and it's an indicator that the processor (CPU, not GPU -- more on that in a minute) has received an instruction that it doesn't have the ability to execute -- a critical fault that you can basically do nothing about. The rest of the crash trace points to a variety of information - the library, memory bits, (I think) entry points, and such.
I didn't do the later analysis, however, reviewing the trace, you can actually pull out the specific instruction (that is -- assembler instruction -- not anything that really reveals anything about the code itself) and you'll discover that the faulting instruction (at least for myself and one other user) was "pshufb". This instruction is *only* available on processors that support SSSE3 (that's "3" S's - Supplimental SSE3) and this set of instructions is only available on the latest 3 generations of AMD processors (it is also missing from some Intel processors, but far fewer). Now, many have pointed out "But I'm only using GPU rendering and it's *still* crashing!". Yup, that's right. The CPU is involved in some way *no matter what*. Or "but it only fails on complex models, not simple ones". Yup. The branch containing the fault may only be hit if certain conditions exist. In a little bit of research I did, this instruction shuffles bits according to a mask. It's commonly used in deinterlacing routines (in most cases hand-optimised assembly). It could be compiler flags, it could be a failure of CPUID to identify the missing SSSE3 support and "picking wrong" for this processor, it could even be hand-optimised inline assembler popped in by the devs to speed up some small, frequently called method that the compiler fails to generate optimal code for (I lean toward the latter case since compilier flag problems often result in larger scale failures and code for things like rendering, enc/decoding and such is usually riddled with hand-optimised routines because you often have a lot of code that's reused/executed over and over again and a couple of ms/ns shaved off of a routine that's called a billion times adds up). Based on just the name of the library, it's also probably not even Daz's code, but something in the Iray library provided by a third-party.
Frankly, all of the research done to figure this out, for me, has saved me some time. I'm no longer bothering to try to workaround the problem. It's simply not going to work on my hardware until the issue is resolved. If you want to confirm that you are experiencing the same problem, grab CPU-Z, run it and take a look at "Instructions". If you see "SSSE3" there (again, not SSE3), you won't run into this specific problem. If you do, you will.
To the several folks who are shocked, just *shocked* that something like this would slip past QA, all I can really say is you're not truly understanding the complexity of this kind of a beast. Native code is *hard*. Take a look at all of those little TLAs that appear in your "Instructions" part of CPU-Z. Those amount to a number of instructions that *your* processor supports. My list is different (maybe it has more, maybe it has less). The permutations of these are exponential. I have written perfectly valid C++ code with correct compiler parameters and *still* had things blow up related to the *compiler* doing something wrong (and if you can't rely ont he compiler to get these things right, you have little to no hope, yourself). Then stack on the fact that the compiler, which in the case of native code generally produces brilliantly fast, very optimised instructions, is *still* not good enough to get *every* optimisation right so now you have to take apart a few routines that are called a billion times during the execution of a render and do the compiler's job for it by hand coding some assembler. I promise you, you're going to miss a platform, especially one that you don't have many (or any) PCs around to test with. Or maybe you saw that pshufb was the *precise instruction* you needed and, *awesome*, it's suported by SSE3 (because, you know, that third "S" was probably written by a programmer who stayed up too late and was a little shaky, or maybe you just missed it the first time your eyes ran over the obscure reference you found to x86_64 assembly because *you're* the programmer staying up too late obsessing over a routine that's taking a couple of nanoseconds too long to execute) and you know that *any* processor that's missing SSE3 *probably* falls outside of the minimum requirements you've set for the app, anyway, so it's *safe*. And, holy crap, it's *fast*. Except when it crashes on a small subset of your customers running hardware you don't have to test with (or maybe you do but your tests don't load the right kind of model to exercise that particular branch). And on and on and on ...
Personally speaking, "all of the guessing" that took place in this post and the other post would have been endlessly helpful to me as a developer. There's *nothing* I like more than when my crash trace actually *provides* enough information for a customer to figure out what went wrong and that customer is able to give me a succint bug report pointing me at what I need to fix (well, short of not having a bug in the first place, but we don't live in fantasy land). Assuming we're all seeing *exactly the same thing* (which, I doubt), I would know where to look and what to do to fix it (with varying degrees of effort involved based on what the nature of the underlying code *is*, which is something only the guy/gal with the source code can identify). Now, I doubt there's just one bug -- even in relation to the crashing that is being talked about in the last few pages here -- but there's at least one bug that has been well identified with bug reports submitted to Daz.
For those of us getting the specific ILLEGAL_INSTRUCTION in neuray.dll, we can all relax. There's almost certainly nothing we can do until the next release and it's in Daz's hands to fix. It's also going to affect enough of a cross-section of their customers that it's not really something they can avoid fixing, so I'd be surprised if it isn't resolved in the next public beta. It sucks to have to wait, especially for folks like me who's only NVidia card and only hardware is among the affected, especially after being able to use Iray GPU accelerated for the first time (albiet on very simple models) and realizing how much faster it is. But such is the nature of wildly complex applications like these (and at the amazingly low price of "give us your e-mail address and maybe buy some models from our store", meanwhile the competition -- which is far buggier with a disgusting UI is incalculably more expensive).
Your diligence is appreciated, trust me, I am a developer and information from someone who has done such is rare and valued. However, guessing about problems in a closed/restricted forum where the participants are all knowledgeable and won't jump to bad conclusions and go screaming that "the world is ending" is far different from speculating in an open forum where the vast majority of the userbase is below novice level about the material being discussed. In cases like this, the signal returns to the developers are so overwhelmed with noise as to be less than useless. In fact, since this was such an anticipated (development/feature-set) far more folks who should not be loading beta software are, and the panic being caused by the unfounded suppositions is being amplified far beyond normal levels because "all they know" is that their systems are now "not working" even though they spent large sums of money on hardware that they were told would magically make their systems faster than greased lightning.
If the problem is indeed on DAZ's side and is actually caused by an opcode with limited scope, then it definitely falls on the "edge".
I have seen 2 valid/probable "guesses" so far in the open forums:
) the opcode issue you have brought up
) 24 bit images vs 32 bit images.
I have another theory, however (as mentioned) it is only a theory and I will not throw it out into an open forum. In my opinion, this is a multifaceted problem that has manifested itself in a manner that is very unfortunate for the circumstances. I am sure that once the Devs have a sure handle on the problem we'll be given information in due course. TBH, I am not altogether sure why they haven't pulled the release already.
Kendall
Kendall -- I've never seen DAZ 'pull' a public beta - they just replace it with a newer version. This beta does provide a way for people to use pascal-based cards they've had for a long time, so it does have benefit. Also, TBH, I don't have a clue as to how big the private beta team is, nor the experience base they draw from. Some of the bugs showing up here show that the base test group has a somewhat limited hardware selection to choose from. And it may be that some of the problem has to go back to nVidia's Iray team, for analysis and fixes, adding to the time for a Studio fix.
For the rest of us - this is beta software. If it works for you, great! If it breaks, please file a support ticket with as much information as you can pull together. If you get a crash, save the report file and attach it to the ticket. Be as specific as you can in the problem description, including your hardware platfform. I might help if you start the subject line with 'DAZ Studio public beta <version>' and then what you're reporting - it will probably get to the dev team faster that way.
...that is the whole purpose of a public beta going live. This way data can be collected through the support mechanism to help solve issues that may not have surfaced in the private testing. No one is under pressure to download and install if they don't want it.
Any idea when the Beta will be updated, I need to make higher res images then the viewport and the waiting is killing me
Can you render to the correct dimensions if the scene is one you created and saved with a prior version? If so, why not open your scene in the release version, set your dimensions, and save. Then open the newly saved scene in the Beta and see if you can render the dimensions you need.
I know it's only a workaround, if it works at all. But this is only a public beta, which pretty much guarantees it will have unresolved issues.
Comments
Public Beta Content 1 DS installed size is 55 Bytes according to DIM. It seems to be a singe "placeholder" text file. Scene Builder is just a single json file.
In DIM, you should have DAZ Studio 4.9 (Win 64-Bit) Public Build +Beta+. That is the 512.1 MB application installer. You would need to copy that to your other computer also.
In DIM I have a path configured for DAZ Studio 4.x Public Build (64-bit), but you are right that there is no such thing in the Applications dropdown selection now in DIM version 1.1.0.64. I wonder if that is a DIM bug? I suggest that you submit a help request about that apparent DIM issue.
We are told this is not a bug but by design.
Well then, how does a person install the Beta with the DIM?
I went through several pages of this but didn't see this issue, so apologies if it's already been discussed. I just installed the beta and it will not render using GPU. If I render with GPU and CPU both ticked, it renders CPU only. I've run GPU shark and I am getting zero cycles and virtually no memory used in the GPU so I'm certain it's not being used.
If I render with GPU ticked and CPU not, it opens a render window and then stops triyng (i.e. instead of cancel the button at the bottom says "close" but there is nothing but the transparant checkerboard. This is with a scene of one light, one plane and one sphere, no textures used so I'm certiain it's not too much to load onto the GPU.
My GPU is a vintage Geoforce 750M, works fine with the current official build. Is there a backwards compatibility issue with the new beta?
When you install the beta DIM creates the path. The problem is trying to install add-ons for the beta before the beta itself has been installed.
Windows or Mac?
Oh! Thanks! Maybe it would be good to add that the the FAQ in post 1.
Windows 8 64bit
Make sure that Daz beta installs first, before installing anything else; I do it seperately, then then rest.
An application always needs to be installed first before any add-ons for said application, otherwise it won't know which application it is for and where it is to be installed.
But to download "beta daz studio zip" by DIM, DIM need to keep online,, if it is not online,, I can not download anything through DIM.
if I have two PC, and PC A is for 3d only,, and can not access internet,, but PC B can access internet, but may not work for 3d,
I may try install DIM on both PC , then anyway download beta by DIM with PC B,, then download , daz studio beta.
then copy and paste it to PC A DIM downloaded directory,, may work?
(though at least , PC B need ability to download and install DIM,,,, as private usage,,)
the best way is,, I think simply DAZ offer beta download package,, in user account,, (I do not know, why daz restrict it,,)
Yes, download on PC B and copy the file over to PC A.
What's the driver version?
And if PC B does not have the same operating system as PC A? My online PC is Linux, and DIM locks up at "Update detected" (update for DIM itself) with "Cannot download update".
Manually update DIM.
My driver version:
That's an old driver, Iray 2016 requires 368 or higher.
For Windows, there isn't a separate CUDA driver package, it's in the 'main' driver package. 352 is definitely too old a driver version to have the necessary CUDA updates for the version of Iray in the beta.
Manually updated DIM.
Followed instructions on product page. Word-for-word.
Studio Beta not showing up at all in Ready to Download section.
And now I can't even get to my products page because of Magneto error.
Thanks, I updated the driver and it works now. I did a render in the official release of an indoor scene (stopped at 12 mins) and saved it, rendered the same scene in the beta for the same duration to see if there was any improvement. Frankly, the official release version seemed a little cleaner. But it's not that different. I was hoping for some good speed improvement like some reported but doesn't seem in the cards for me. Anyway thanks for the suggestions, glad its working now.
Fresh install of DIM, running in WINE.
Followed instructions on product page. Nothing showed up in DIM.
Got lucky - sort of - DAZ logged me out, product page went from red "purchased" to green "purchase".
Clicked "purchase", logged back in. Completed purchase.
Beta shows up in DIM. Downloads at 1.1mbs to 99%.
Download stops. 0.0mbs.
Download fails.
I give up. Wasn't sure if I wanted 10XX series card anyway, waiting for Studio comparisions with my 980ti.
Might buy another 980ti.
Any idea when the Beta will be updated, I need to make higher res images then the viewport and the waiting is killing me
Nothing has been said - this is the thread in which it wold be posted. In the emantime, do you not have any saved scenes with alrger dimensions?
I actually hadn't even noticed this problem in my testing because I've been using a set of scripts to change my resolution to the ones I normally use.
Save the lines above in a script and change the width and height variables to your desired resolution. aWidth and aHeight are used to set the aspect ration, so 1920x1080 should set those to 16 and 9 respectively.
saving this as a script and executing it - it changes to the desired resolution - but only in the viewport .... it still renders only the WHOLE viewport.
I was testing with an old scene and tried to render through the camera I saved month ago.
No when got my new pc I transferred everything over from my macbook, all my previous scenes I used a 4K Preset which I cant do with my new 1070 :(
I render 4K images so I dont think that will work :( Plus I have no idea how to do what you just said
Kendall -- I've never seen DAZ 'pull' a public beta - they just replace it with a newer version. This beta does provide a way for people to use pascal-based cards they've had for a long time, so it does have benefit. Also, TBH, I don't have a clue as to how big the private beta team is, nor the experience base they draw from. Some of the bugs showing up here show that the base test group has a somewhat limited hardware selection to choose from. And it may be that some of the problem has to go back to nVidia's Iray team, for analysis and fixes, adding to the time for a Studio fix.
For the rest of us - this is beta software. If it works for you, great! If it breaks, please file a support ticket with as much information as you can pull together. If you get a crash, save the report file and attach it to the ticket. Be as specific as you can in the problem description, including your hardware platfform. I might help if you start the subject line with 'DAZ Studio public beta <version>' and then what you're reporting - it will probably get to the dev team faster that way.
...that is the whole purpose of a public beta going live. This way data can be collected through the support mechanism to help solve issues that may not have surfaced in the private testing. No one is under pressure to download and install if they don't want it.
Can you render to the correct dimensions if the scene is one you created and saved with a prior version? If so, why not open your scene in the release version, set your dimensions, and save. Then open the newly saved scene in the Beta and see if you can render the dimensions you need.
I know it's only a workaround, if it works at all. But this is only a public beta, which pretty much guarantees it will have unresolved issues.