OTOY Forums

I have updated the STABLE build at the top of this thread with:

4.01.1.88 (13-Dec-2018)
- Compiled with Octane 4.01.1

Please note there there is a know issue where the GPU free and used RAM is not being displayed correctly in some instances if you have multiple cards. This will be fixed in the next release.

Thanks

Paul

Hi Paul,

good news, I haven't had one single crash since I installed this update. Easily the most stable build of Octane/ArchiCAD Plugin I've used.

Question, how do you use the light linking in the ArchiCAD plugin? I've assigned light link ID's to the different 'lamp' materials I have, but after I set the Light Link ID's action to 'enabled', I'm not sure how to define the 'Light ID's [Bit Mask]. If you could provide a bit of guidance on how to use this would be great.

Cheers, Dan.

Question, how do you use the light linking in the ArchiCAD plugin? I've assigned light link ID's to the different 'lamp' materials I have, but after I set the Light Link ID's action to 'enabled', I'm not sure how to define the 'Light ID's [Bit Mask]. If you could provide a bit of guidance on how to use this would be great.

Hi Dan. Light Linking is not currently supported by the plugin, and even if you export to Octane Standalone it will be of limited value, because the plugin loads all the scene geometry into a single Octane Mesh node, so there would be no ability to turn on/off lights for different geometry items.

Thanks

Paul

I have been a long time out of the loop with Octane, but having upgraded to this version (4.01.1.88) am noting that the material selection using eyedropper in viewport is not working properly at all. Over most of viewport image, no material can be selected at all, and where I can get a response, the wrong material is selected.

I suspect there is a DPI scaling issue with the ArchiCAD plugin viewport? The behaviour I am seeing is consistent with the eyedropper selections being sampled from a different location on the image than where the mouse pointer/eyedropper is being displayed - whether this difference is a consistent linear offset from mouse pointer or a scaled difference I am not sure.

I do know that Microsoft changed the way Windows 10 handles UI elements (like mouse pointers) within applications, early last year, supposedly to make them scale better for large format displays

In my testing, the issue indeed goes away when I change windows display scaling from 150% (default) to 100% - though of course on any modern workstation with a standard 4K display, this is not a very useful or workable solution, as 100% display scaling leaves most windows UI elements and text near-invisibly small.

Another related bug is that the viewport image does not correctly fill the extents of the ArchiCAD viewport window unless display scaling is dropped down to 100%.

Another possible bug: Even when ArchiCAD is loading all objects and textures from an uncompressed folder (i.e. not an .lcf and not embedded), most textures are not coming through.
Cuda log reports no errors, and selecting the texture and using the 'Reconvert From ArchiCAD material' function does nothing.

Possibly ignorance on my part, but I don't seem to recall this being an issue before, except when ArchiCAD textures were being loaded from an lcf.

Not a world ending issue, as most standard ArchiCAD textures I would want to change anyway, but it does make locating and distinguishing between the various textures difficult in the viewport when all are rendering as white.

I have been a long time out of the loop with Octane, but having upgraded to this version (4.01.1.88) am noting that the material selection using eyedropper in viewport is not working properly at all. Over most of viewport image, no material can be selected at all, and where I can get a response, the wrong material is selected.

I suspect there is a DPI scaling issue with the ArchiCAD plugin viewport? The behaviour I am seeing is consistent with the eyedropper selections being sampled from a different location on the image than where the mouse pointer/eyedropper is being displayed - whether this difference is a consistent linear offset from mouse pointer or a scaled difference I am not sure.

I do know that Microsoft changed the way Windows 10 handles UI elements (like mouse pointers) within applications, early last year, supposedly to make them scale better for large format displays

In my testing, the issue indeed goes away when I change windows display scaling from 150% (default) to 100% - though of course on any modern workstation with a standard 4K display, this is not a very useful or workable solution, as 100% display scaling leaves most windows UI elements and text near-invisibly small.

Another related bug is that the viewport image does not correctly fill the extents of the ArchiCAD viewport window unless display scaling is dropped down to 100%.

Both these issues are fixed in the next release.

Another possible bug: Even when ArchiCAD is loading all objects and textures from an uncompressed folder (i.e. not an .lcf and not embedded), most textures are not coming through.
Cuda log reports no errors, and selecting the texture and using the 'Reconvert From ArchiCAD material' function does nothing.

Possibly ignorance on my part, but I don't seem to recall this being an issue before, except when ArchiCAD textures were being loaded from an lcf.

Not a world ending issue, as most standard ArchiCAD textures I would want to change anyway, but it does make locating and distinguishing between the various textures difficult in the viewport when all are rendering as white.

Can you send me a scene where this happens please?

Thanks

Paul

face_off wrote:Can you send me a scene where this happens please?

Thanks

Paul

I have unfortunately since worked on the file to the point all textures have been manually replaced with Octane textures, and cannot now seem to recreate the issue. either with current file, or from scratch.

I am wondering if the process I went through might have somehow 'cleared' something - perhaps some garbage left over from earlier plugin version. Possible also a couple of reboots helped along the way.

I have updated the TEST installer for AC22 at the top of this thread with:

4.01.1.89
- Fixed "Removed the Cuda Devices list, and replaced with the Octane Standalone Devices panel" which was missing from the previous release
- Fixed issues associated with 4k monitors
- Potential fix to the material picker issues that have been reported
- Added "Import from LiveDb/LocalDB - EXPERIMENTAL" in the material tab menu

Thanks

Paul

face_off wrote:I have updated the TEST installer for AC22 at the top of this thread with:

4.01.1.89
- Fixed "Removed the Cuda Devices list, and replaced with the Octane Standalone Devices panel" which was missing from the previous release
- Fixed issues associated with 4k monitors
- Potential fix to the material picker issues that have been reported
- Added "Import from LiveDb/LocalDB - EXPERIMENTAL" in the material tab menu

Thanks

Paul

Currently without my 4K monitor, but material picker now is working for me when display scaling is > 100%

I have updated the STABLE release at the top of this thread with:

4.02.0.90 (28-Jan-2019)
- Compiled with Octane 4.02
- Fixed error in "Import from LiveDb/LocalDB - EXPERIMENTAL" which could lead to a "No material node found" error or a crash

4.01.1.89 (24-Jan-2019)
- Fixed "Removed the Cuda Devices list, and replaced with the Octane Standalone Devices panel" which was missing from the previous release
- Fixed issues associated with 4k monitors. Not supported in AC20 and AC21.
- Potential fix to the material picker issues that have been reported. Not supported in AC20 and AC21.
- Added "Import from LiveDb/LocalDB - EXPERIMENTAL" in the material tab menu

Thanks

Paul