OcDS 2.1 PRE RELEASE 5th

DAZ Studio Integrated Plugin (Integrated Plugin maintained by OTOY)

Moderator: BK

Forum rules
Please keep character renders sensibly modest, please do not post sexually explicit scenes of characters.
Post Reply
User avatar
larsmidnatt
Licensed Customer
Posts: 499
Joined: Tue Sep 25, 2012 12:28 pm

so I tried some more daring stuff. Still not extensive testing but merging file with itself seems to work, autofit works but geografting is still worse than it was in 1.0. One of the reasons I stuck with 1.0 is because you can apply geo-graphs without it totally destroying the figure. in 1.2 forward the geograph region may look OK, but then your characters eye lashes and limbs may totally disappear!

while pressing the final button is no longer a guaranteed crash, it still has a tendency to do that or become non-responsive for long periods of time with no status indication or feedback.

The size aspect ration option doesn't seem to remember what I have selected. If i set it to 3:4, the save, close reload it switches to custom.

Emitters still have strange behavior. For example I load a 1 foot plane to the scene. I change mat from glossy to diffuse. I add an texture emission to it. in 1.0 it would work and render. Currently the material link seems to work for a second, but after i rotated the plane the material link broke. and you have to relink it.
Win10 x64
i9 10900k 64GB
2080S 8GB
DS 4.15 OcDS Prime ^_^
User avatar
DrHemulen
Licensed Customer
Posts: 317
Joined: Thu Dec 26, 2013 7:09 pm

Geografting is just plain weird.

I've got it working perfectly (well, so far) in 1.2 with at script that goes in and rewrites the material strings in the .duf file. I've had the odd geo misalignment, but that was probably because of a badly saved graft on my part.

I'll play around with 2.1 and grafting after Christmas and see if I can get the script working there. That may give some info on what's going on.
GTX 780, 6 gigs of VRAM - Win 7 Home Premium 64 bits
User avatar
t_3
Posts: 2871
Joined: Tue Jul 05, 2011 5:37 pm

larsmidnatt wrote:while pressing the final button is no longer a guaranteed crash, it still has a tendency to do that or become non-responsive for long periods of time with no status indication or feedback.
collapsing (=final) currently just messes up any but the 1st object mesh; this causes octane to get insane while building the geometry. soon to be fixed.
larsmidnatt wrote:The size aspect ration option doesn't seem to remember what I have selected. If i set it to 3:4, the save, close reload it switches to custom.
that's correct. apparently i just forgot to save the value.

will need to look into the emitter thing; can you pls submit a report? if you click the link in the plugin you only need a few clicks to complete it (depending on how detailed you explain it ;))
The obvious is that which is never seen until someone expresses it simply

1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
User avatar
sikotik13
Licensed Customer
Posts: 270
Joined: Thu Feb 20, 2014 6:21 pm
Location: Iowa, United States

Random note, and may be something I broke somewhere:

I have a particular scene (just a collection of Greenpot's school, assembled correctly for Daz Studio without benefit of Poser scripts). I have tried removing (nearly) all extraneous props (there are a lot), clearing all maps from everything (as I will not use them anyway), and even switching everything to omnifreaker's SimpleSurface shader (to make sure there was nothing I forgot to get rid of. This scene refuses to open in the viewport. No error report, straight to desktop, as soon as it finishes loading any materials (if auto or .duf), or upon attempting to assign any (if manual). I am running out of options at this point for simple user error, and in fact the full set with all props and textures loads up just fine in OcDS 1.2. It also loads fine as modified for 2.15 within 1.2, if rather faster (which was the intent).

It seems I can load each section individually in 2.15, but each takes as long or longer as it takes to open the entire assembly in 1.2, negating the usefulness of assembling them in the first place.

I only made it through half of the first floor before I decided it was taking entirely too long (read: about an hour. Parts loaded in Daz Studio in seconds each, materials would list as loading in OcDS. At some point on the last material [I'm assuming it's the last, they flash through very quickly until this point], OcDS would seem to hang for upwards of 10 minutes loading the blank white material, then still have said material listed in the information panel as loading while the scene was finally accessible). I'm assuming that this hang on the last material is compounded when all of the parts are loaded together, and does something crazy, but it's not logged anywhere I can find (scoured the Daz log, which never even shows the crash, just the many times I restarted Daz Studio).

Attempted with 4.7 pro and Beta, verified set still works with 4.7 beta rolled back to OcDS 1.2. I'll try to send a crash log later, but I'm not sure if anything's there, since my RAM is immediately flushed on the CTD, which didn't happen even with the other one I reported through the link.

Is there an implied texture count limit (as in how many surfaces there can be total)? The scene is not necessarily polygon complex (roughly on par with two or three Genesis 2 figures, which I can do just fine), and I figured cutting down the materials used to basically none would alleviate the issue, but no dice so far. The system tab is greyed out during the load, so I don't know if it ever shows anything useful, but it vaguely reminds me of deleting a .wim file. Windows gets confused by the compression of compresed files, all of which are pretty small, and ends up eventually saying a single 1.9 GB .wim file is somewhere in the trillions of files spanning millions of GBs, but ends up deleting it just fine. I'm guessing it's something similar? Like it's looking for more stuff that isn't there, and running out of virtual memory, perhaps. Pure speculation on my part, of course, but I'll get that log sent over here in a bit, before I head out of town for the week.

It's still a vast improvement overall, and since this is the only thing I use commonly that's managed to stump it outside of the other things I reported, I'm still quite impressed with the progress. Excellent job!

Oh! And merry Christmas everyone!
| Intel i7-5960x @ 3.8 GHz| ASUS X99-E WS | 64 GB G.Skill DDR4 2400 Ram | 4x EVGA GTX 980 Ti | Win10 Professional x64 | Watercooled
User avatar
larsmidnatt
Licensed Customer
Posts: 499
Joined: Tue Sep 25, 2012 12:28 pm

t_3 wrote: will need to look into the emitter thing; can you pls submit a report? if you click the link in the plugin you only need a few clicks to complete it (depending on how detailed you explain it ;))
They in general just still are really buggy. One bug isn't reproducible cause you'll get a different bug. I can make a new scene, only make a plane and attach a texture emission to it and it wont ever render right or be recognized as an emitter. I'll send a ticket
Win10 x64
i9 10900k 64GB
2080S 8GB
DS 4.15 OcDS Prime ^_^
User avatar
larsmidnatt
Licensed Customer
Posts: 499
Joined: Tue Sep 25, 2012 12:28 pm

I have to say that 2.x is just so fast compared to older versions. I saw this trend in the earlier pre releases too, but I didn't use them quite as much as this one because of some basic challenges. But I'm feeling very fast responsiveness in most areas, setting changes are visible in "real-time" :lol: . I know a lot of this has to do with Octane improvements and not just the plugin changes but overall the pairing is coming along really well. I'm very excited for future releases.

Even simple changes like imager adjustments are way faster than before.

What is noticeable slower is any geometry pose/morph updates. I read the notes about that. Not a deal breaker, understandable. I just changed my settings for latency to (slow PC) and maybe that will help. Or I'll just end up turning off live update or whatever. The great thing is we do have plenty of ways to manage performance :)

I just came up with a new test...might not get to it tonight. Anyone tried rendering Andrey P's Tropical Bundle with 2.x. I did it back with 1.0 and will give that whirl :)

so far Geo-grafting is the big hold up for me :/ I'll keep trying to break the plugin though and see what else I can find.
Win10 x64
i9 10900k 64GB
2080S 8GB
DS 4.15 OcDS Prime ^_^
User avatar
t_3
Posts: 2871
Joined: Tue Jul 05, 2011 5:37 pm

larsmidnatt wrote:What is noticeable slower is any geometry pose/morph updates.
... and of course with every genesis gen. the poly count also went up; what you may try is the "use base geometries" switch (in the preferences). the idea behind this was to have faster updates during tweaking ("final" - once usable - allows to override it). since i had no time to do serious stuff myself i can't say how much it is worth, but as soon at least a subd level of 1 is in use, it should be noticeable...
The obvious is that which is never seen until someone expresses it simply

1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
User avatar
larsmidnatt
Licensed Customer
Posts: 499
Joined: Tue Sep 25, 2012 12:28 pm

t_3 wrote:
larsmidnatt wrote:What is noticeable slower is any geometry pose/morph updates.
... and of course with every genesis gen. the poly count also went up; what you may try is the "use base geometries" switch (in the preferences). the idea behind this was to have faster updates during tweaking ("final" - once usable - allows to override it). since i had no time to do serious stuff myself i can't say how much it is worth, but as soon at least a subd level of 1 is in use, it should be noticeable...
well its way faster in 1.0 than 2.x, so I just think its related to how the plugin works now. I can keep the latency setting to fast on my i5 machine with 1.0 and not notice any impact on DS usage. But with 2.x, the plugin locks DS so you can't do any changes while it is catching up(and im on an I7 now...). I often work with the models at base resolution until I'm ready to render anyway... my most recent testing was done this way.

Simply put, the new plugin locks daz when you are trying to pose a figure so it can catch up. The old plugin didn't do this. I just tested again to confirm.

I'll keep tinkering around.
Win10 x64
i9 10900k 64GB
2080S 8GB
DS 4.15 OcDS Prime ^_^
User avatar
larsmidnatt
Licensed Customer
Posts: 499
Joined: Tue Sep 25, 2012 12:28 pm

OK probably better way to explain it. While the octane viewport is GREY you can't do anything in daz studio (for the most part). 1.0 never went grey to do updates so you were always able to keep moving along and not care if octane has caught up yet.

I tried using base geometry, same issues. But I can work around it. I think part of the issue is related to the fact some objects are high poly at BASE resolution. Not talking genesis figures, but V4 hair even(the pre-sub-d stuff obviously). While daz is willing to keep going, Octane is trying to catch up. It's just a new thing to cope with in 2.0 that we didn't have in 1.0 but I'm ok with it. Fast updates aren't always needed and for posing I tend to try and hammer that out in the DS viewport anyway. I felt it was worth mentioning but nothing to be concerned over.

So 1.0 may not have really been faster at updating, it just didn't stop you from using DS while it was working. So it felt smoother. But I have my way to make things feel smooth in 2.x :)
Win10 x64
i9 10900k 64GB
2080S 8GB
DS 4.15 OcDS Prime ^_^
User avatar
t_3
Posts: 2871
Joined: Tue Jul 05, 2011 5:37 pm

ok. i forgot you are comparing against 1.0; back then octane wasn't able to do multitasked mesh building so the plugin instead did run mesh building in multiple tasks; that indeed had (apart from being fast) also the advantage of a responsive ui. not only is octane now able to do mesh building multitasked, but it also does it more efficiently - this on the other hand means that it uses notable more system resources (cpu), thus the ui becomes unresponsive...
The obvious is that which is never seen until someone expresses it simply

1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
Post Reply

Return to “DAZ Studio”