OTOY Forums

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

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

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 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

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.

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

I have updated the installers at the top of this thread with:

2019.1.1.46
- Compiled with Octane 2019.1.1

Thanks

Paul

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.

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.

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