OctaneRender 2019 for DAZ Studio [OBSOLETE]

Forums: OctaneRender 2019 for DAZ Studio [OBSOLETE]
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.

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby face_off » Tue Sep 24, 2019 6:26 am

face_off Tue Sep 24, 2019 6:26 am
Upgraded my license and installed 2019.1

Everything fine so far. Besides IES lights.

In 2019.1 RC 3 they were kind of broken. When the plane got tilted they still were shining straight down.

With 2019.1 light distribution doesnt work anymore at all. used the standard octane IES profiles.

Can someone confirm?

Is this a plugin or a standalone problem?
Can you send me a scene with just an emitter plane in it which demonstrates this issue please?

Paul
Win7/Win10/Mavericks/Mint 17 - GTX550Ti/GT640M
Octane Plugin Support : Poser, ArchiCAD, Revit, Inventor, AutoCAD, Rhino, Modo, Nuke
Pls read before submitting a support question
User avatar
face_off
Octane Plugin Developer
Octane Plugin Developer
 
Posts: 15471
Joined: Fri May 25, 2012 10:52 am
Location: Adelaide, Australia

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby face_off » Tue Sep 24, 2019 6:29 am

face_off Tue Sep 24, 2019 6:29 am
I'm not a programmer, but if you are saying that handling pins is so different between DAZ and OTOY, wouldn't it be possible to separate these two worlds on the plugin level so DAZ would be providing geometry and material zones and the plugin would handle everything else in the pure OTOY way - I would not even mind if scene save would then produce two files - the DAZ scene file that would have all the DAZ information and some sort of XML (or proprietary) that would store the OTOY part for that scene (if this information is so different from the format DAZ uses and thus it is impossible to store it within the DAZ file itself). I'm sure that this would mean a lot of work - most probably a complete rewrite of the plugin, but wouldn't this result in future-proofing the plugin as it would gain freedom from constraints of DAZ and give it ability to use all present and future features OTOY brings in?
Yes - what would be great is if all the Octane Materials in the plugin were edited in the Octane Standalone nodegraph. That would address this specific issue. It would however require a major overhaul of the code, and existing plugin scene would loose their materials when loaded into the new version of the plugin.

Paul
Win7/Win10/Mavericks/Mint 17 - GTX550Ti/GT640M
Octane Plugin Support : Poser, ArchiCAD, Revit, Inventor, AutoCAD, Rhino, Modo, Nuke
Pls read before submitting a support question
User avatar
face_off
Octane Plugin Developer
Octane Plugin Developer
 
Posts: 15471
Joined: Fri May 25, 2012 10:52 am
Location: Adelaide, Australia

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby birdovous » Tue Sep 24, 2019 6:55 am

birdovous Tue Sep 24, 2019 6:55 am
face_off wrote:
I'm not a programmer, but if you are saying that handling pins is so different between DAZ and OTOY, wouldn't it be possible to separate these two worlds on the plugin level so DAZ would be providing geometry and material zones and the plugin would handle everything else in the pure OTOY way - I would not even mind if scene save would then produce two files - the DAZ scene file that would have all the DAZ information and some sort of XML (or proprietary) that would store the OTOY part for that scene (if this information is so different from the format DAZ uses and thus it is impossible to store it within the DAZ file itself). I'm sure that this would mean a lot of work - most probably a complete rewrite of the plugin, but wouldn't this result in future-proofing the plugin as it would gain freedom from constraints of DAZ and give it ability to use all present and future features OTOY brings in?
Yes - what would be great is if all the Octane Materials in the plugin were edited in the Octane Standalone nodegraph. That would address this specific issue. It would however require a major overhaul of the code, and existing plugin scene would loose their materials when loaded into the new version of the plugin.

Paul

Hmm... about loosing the scene information of older scenes - the present plugin is able to export the scene with the currently supported features (as they are supported by the plugin) into standalone, therefore it should be possible for the rewritten plugin to detect the old scene format and upon opening the file for the first time utilize this "export logic" we already have to convert the old material format to the "new" one and work with it from that point on? And yeah I'm aware that it is all easier said than done. Because... Anything is possible when you don't know what you are talking about... (usually my case) ;)
Birdovous
Master: Core i7 2600K, 32GB RAM, 2x EVGA GTX Titan X (SC)
Slave 1: Core i5 4460, 16GB RAM, 2x EVGA GTX 1080 Ti SC2
Slave 2: Core i7 9700K, 64GB RAM, 2x ASUS RTX 2080 Ti
User avatar
birdovous
Licensed Customer
Licensed Customer
 
Posts: 155
Joined: Tue Jul 23, 2013 5:33 pm

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby rajib » Sat Oct 05, 2019 4:38 am

rajib Sat Oct 05, 2019 4:38 am
birdovous wrote:
face_off wrote:
I'm not a programmer, but if you are saying that handling pins is so different between DAZ and OTOY, wouldn't it be possible to separate these two worlds on the plugin level so DAZ would be providing geometry and material zones and the plugin would handle everything else in the pure OTOY way - I would not even mind if scene save would then produce two files - the DAZ scene file that would have all the DAZ information and some sort of XML (or proprietary) that would store the OTOY part for that scene (if this information is so different from the format DAZ uses and thus it is impossible to store it within the DAZ file itself). I'm sure that this would mean a lot of work - most probably a complete rewrite of the plugin, but wouldn't this result in future-proofing the plugin as it would gain freedom from constraints of DAZ and give it ability to use all present and future features OTOY brings in?
Yes - what would be great is if all the Octane Materials in the plugin were edited in the Octane Standalone nodegraph. That would address this specific issue. It would however require a major overhaul of the code, and existing plugin scene would loose their materials when loaded into the new version of the plugin.

Paul

Hmm... about loosing the scene information of older scenes - the present plugin is able to export the scene with the currently supported features (as they are supported by the plugin) into standalone, therefore it should be possible for the rewritten plugin to detect the old scene format and upon opening the file for the first time utilize this "export logic" we already have to convert the old material format to the "new" one and work with it from that point on? And yeah I'm aware that it is all easier said than done. Because... Anything is possible when you don't know what you are talking about... (usually my case) ;)


Hi Paul,

What birdovous mentioned should be doable. Lets say for new scene you create a .DazOctane file which will contain all materials in native OTOY definition. So when a scene is opened and that file is missing, you auto create the .DazOctance file by exporting the current material info stored with the scene file to OTOY native format. Then call the actual new scene loading function which will read the material definitions from the .DazOctane file. Then onward any changes done in the NGE / Quick Material editor can be saved in the .DazOctane file and all other Octane details stored within the DazScene except for the material ID mapping (plus what is necessary) can be removed from the Daz scene file.

In fact if you need to change the complete Octane plugin interface to a node based interface like in the Standalone, that too I don't think anyone will mind.

You can give also us a standalone application that will create this .DazOctane file for existing scene. That way this 'OTOY' material file will be present when the scene is opened.

I hope you can put some thought to this. This way you will have complete control over how the material is stored. I know we will still have some issues with IRAY MDL to OSL / OTOY Native material conversions, but at least after that whatever we do in NGE will be OTOY / OSL material based and will not have any more restrictions. And in the future if OTOY one day supports MDL, then all conversions will work.

Regards,
Rajib
Last edited by rajib on Sat Oct 05, 2019 5:08 am, edited 1 time in total.
Windows 10 Pro i9-9980XE 128GB RAM|4 x Titan RTX
Houdini 18.5(2020.2.1.2)|Cinema C4D R26|Daz Studio Pro 4.21.0.5(Octane 2021.1.6.83)
NVIDIA 460.89 Studio Standard
User avatar
rajib
Licensed Customer
Licensed Customer
 
Posts: 401
Joined: Sun Sep 28, 2014 4:57 am

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby rajib » Sat Oct 05, 2019 5:05 am

rajib Sat Oct 05, 2019 5:05 am
rajib wrote:Hi Paul,

What birdovous mentioned should be doable. Lets say for new scene you create a .DazOctane file which will contain all materials in native OTOY definition. So when a scene is opened and that file is missing, you auto create the .DazOctance file by exporting the current material info stored with the scene file to OTOY native format. Then call the actual new scene loading function which will read the material definitions from the .DazOctane file. Then onward any changes done in the NGE / Quick Material editor can be saved in the .DazOctane file and all other Octane details stored within the DazScene except for the material ID mapping (plus what is necessary) can be removed from the Daz scene file.

In fact if you need to change the complete Octane plugin interface to a node based interface like in the Standalone, that too I don't think anyone will mind.

You can give also us a standalone application that will create this .DazOctane file for existing scene. That way this 'OTOY' material file will be present when the scene is opened.

I hope you can put some thought to this. This way you will have complete control over how the material is stored. I know we will still have some issues with IRAY MDL to OSL / OTOY Native material conversions, but at least after that whatever we do in NGE will be OTOY / OSL material based and will not have any more restrictions. And if the future if OTOY one day supports MDL, then all conversions will work.

Regards,
Rajib


One other thing Paul, if you are willing, I would like to help you write this scene conversion logic for existing scene. I do not mind signing any NDA with OTOY / you. And I do not need any payment for it. As long as I am given how the current data is stored within Daz scene file that is used by Octane and the export logic and how the Otoy native format is, I should be able to help you write it. I have Visual Studio and DAZ SDK. I can install the QT component, I have VS2015, VS2017 and VS2019. I think DAZ is based on VS2010 which I should be able to target. Do let me know if this would be of help to you. I really want to do this so that I can use Octane to its full potential with Daz.
Windows 10 Pro i9-9980XE 128GB RAM|4 x Titan RTX
Houdini 18.5(2020.2.1.2)|Cinema C4D R26|Daz Studio Pro 4.21.0.5(Octane 2021.1.6.83)
NVIDIA 460.89 Studio Standard
User avatar
rajib
Licensed Customer
Licensed Customer
 
Posts: 401
Joined: Sun Sep 28, 2014 4:57 am

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby face_off » Mon Oct 07, 2019 11:13 am

face_off Mon Oct 07, 2019 11:13 am
Lets say for new scene you create a .DazOctane file which will contain all materials in native OTOY definition.
In general, having an additional file which contains scene data can get pretty confusing to users (particularly those less technically inclined). They will move the normal DAZStudio scene file, and not the .DazOctane file and wonder where their materials went. And then renaming the DAZStudio scene file unlinks the 2 files too. All Octane plugins store their data in the host app scene files, and I think this is the way it needs to be.

This way you will have complete control over how the material is stored. I know we will still have some issues with IRAY MDL to OSL / OTOY Native material conversions, but at least after that whatever we do in NGE will be OTOY / OSL material based and will not have any more restrictions.
Moving to a native Octane nodegraph would remove the templating system currently in place, which I think you would agree is essential for supporting the DAZ human figures. The actual storage of the Octane nodegraph is relatively simple, since it is XML and could be stored in the DAZStudio scene file.

I would like to help you write this scene conversion logic for existing scene.
This is something you would need to discuss with OTOY. I think you would need to be able to work full time for a couple of months achieve anything - don't underestimate the magnitude of the task :-)

Thanks

Paul
Win7/Win10/Mavericks/Mint 17 - GTX550Ti/GT640M
Octane Plugin Support : Poser, ArchiCAD, Revit, Inventor, AutoCAD, Rhino, Modo, Nuke
Pls read before submitting a support question
User avatar
face_off
Octane Plugin Developer
Octane Plugin Developer
 
Posts: 15471
Joined: Fri May 25, 2012 10:52 am
Location: Adelaide, Australia

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby face_off » Mon Oct 07, 2019 11:20 am

face_off Mon Oct 07, 2019 11:20 am
I have updated the installers at the top of this thread with:

2019.1.1.46
- Compiled with Octane 2019.1.1

Thanks

Paul
Win7/Win10/Mavericks/Mint 17 - GTX550Ti/GT640M
Octane Plugin Support : Poser, ArchiCAD, Revit, Inventor, AutoCAD, Rhino, Modo, Nuke
Pls read before submitting a support question
User avatar
face_off
Octane Plugin Developer
Octane Plugin Developer
 
Posts: 15471
Joined: Fri May 25, 2012 10:52 am
Location: Adelaide, Australia

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby rajib » Mon Oct 07, 2019 1:20 pm

rajib Mon Oct 07, 2019 1:20 pm
face_off wrote:
Lets say for new scene you create a .DazOctane file which will contain all materials in native OTOY definition.
In general, having an additional file which contains scene data can get pretty confusing to users (particularly those less technically inclined). They will move the normal DAZStudio scene file, and not the .DazOctane file and wonder where their materials went. And then renaming the DAZStudio scene file unlinks the 2 files too. All Octane plugins store their data in the host app scene files, and I think this is the way it needs to be.
I don't think this is a real concern. I have not moved a scene file from my standard folder in years and I don't think anyone constantly moves files around. And if they do, after the first time of not copying the .DazOctane file, they will remember it next time.

This way you will have complete control over how the material is stored. I know we will still have some issues with IRAY MDL to OSL / OTOY Native material conversions, but at least after that whatever we do in NGE will be OTOY / OSL material based and will not have any more restrictions.
Moving to a native Octane nodegraph would remove the templating system currently in place, which I think you would agree is essential for supporting the DAZ human figures. The actual storage of the Octane nodegraph is relatively simple, since it is XML and could be stored in the DAZStudio scene file.
In that case, storing the Octane specific data should not be a problem within the daz scene file. I do not know how important people think tempting is, I have not used it myself much. But yes, others may be using it often. And frankly I do not see why templating like feature cannot be added even if we go for a node based system. Just add a button that when clicked with read the template, read the actual daz material and fill the template nodes and create the nodes in the NGE. Frankly this should be simple to implement. You own the code so you are not restricted by what buttons / features Octane adds, you can easily add additional functionality on top of what OTOY provides.

I would like to help you write this scene conversion logic for existing scene.
This is something you would need to discuss with OTOY. I think you would need to be able to work full time for a couple of months achieve anything - don't underestimate the magnitude of the task :-)

Thanks

Paul


Will check with OTOY on this.
Windows 10 Pro i9-9980XE 128GB RAM|4 x Titan RTX
Houdini 18.5(2020.2.1.2)|Cinema C4D R26|Daz Studio Pro 4.21.0.5(Octane 2021.1.6.83)
NVIDIA 460.89 Studio Standard
User avatar
rajib
Licensed Customer
Licensed Customer
 
Posts: 401
Joined: Sun Sep 28, 2014 4:57 am

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby rajib » Mon Oct 07, 2019 1:22 pm

rajib Mon Oct 07, 2019 1:22 pm
face_off wrote:I have updated the installers at the top of this thread with:

2019.1.1.46
- Compiled with Octane 2019.1.1

Thanks

Paul


Thanks. Just downloaded. Will test it out.
Windows 10 Pro i9-9980XE 128GB RAM|4 x Titan RTX
Houdini 18.5(2020.2.1.2)|Cinema C4D R26|Daz Studio Pro 4.21.0.5(Octane 2021.1.6.83)
NVIDIA 460.89 Studio Standard
User avatar
rajib
Licensed Customer
Licensed Customer
 
Posts: 401
Joined: Sun Sep 28, 2014 4:57 am

Re: OctaneRender 2019 for DAZ Studio [TEST and STABLE]

Postby p3taotoy » Mon Oct 14, 2019 7:09 pm

p3taotoy Mon Oct 14, 2019 7:09 pm
NEW to DAZ plugin
Familiar with Octane in general though.
I searched for rendering Hair tips and found some that mentioned that turning PR ON and Line thickness to 2 or above in simulation helped and YES it does.... but I also saw some mention that the plugin has some issues with even these work arounds that was core to the native code itself. Forgive me if I have this all wrong but that is the gist I got.

My situation:

I am able to render the hair on a Yeti model ONLY if I start from scratch each time. If I am successful and then save the scene and then reopen it the hair is lost even though the settings are saved in the Hair simulation settings as above.

In addition I can get the T pose saved and then rendered with volumes of hair etc ... but if i apply a pose the hair is lost upon render even with a force reload.

Does this sound like it is related to the core code issue mentioned in previous forum entries.... or something more memory related given I am successful once. I even was able to export an ORBX and the standalone can see the hair etc. But if the hair does not show in octane render view port the export to ORBX is also hairless.

Is there something crucial I am missing or is it just a hair issue.... is there a way to export JUST the hair as an OBJ ... if I un parent it it (the hair) goes back to t-Pose ... can I somehow keep the posed state and export the hair and geometry separately as OBJ etc?


Thanks
p3taotoy
Licensed Customer
Licensed Customer
 
Posts: 182
Joined: Sat Nov 24, 2018 1:06 am
Location: Washinghton, USA and Waikanae, New Zealand
PreviousNext

Return to DAZ Studio


Who is online

Users browsing this forum: No registered users and 8 guests

Thu Mar 28, 2024 1:20 pm [ UTC ]