Python Api - Render layers - Breaks lights

[Bob.Bon2000]

Hey

If I apply raytracing property to a light via python script.

It would create a raytracinggeoAttachment on a light>

It will break native light controls >

And they no longer do anything to light... Primary vis/visible to refl.

Can this be fixed so that these controls still work despite lights having raytracing attachments?

We have our own layer system running and we consider lights behaviour to be accurate when treated/controlled as a layer entity like geo/etc.

It would be great if this did not break UI/work!

Thanks!

[Bob.Bon2000]

Currently were fixing it via node.subAttachment(), but that is all deprecated, please don't remove that logic till V2 is supporting adding/removing/editing node attachments. 

[michael_nikelsky]

I am not sure what you do to attach this attachment to a light node, when apply a renderlayer it is explicitly only applied to geometry nodes, everything else is an illegal configuration. However, what happens here is that you are actually overriding the internal attachment on the light source which is a bad thing.

Doing low level things like this is always dangerous and can result in broken results and there is no way for us to detect or prevent this. That´s why the V2 Python API tries to avoid allowing things that break your scene like this.

[Bob.Bon2000]

Hey

Yeah I didn't do it on purpose, but doing, python simply (I can't rememberthe  command of top of my head) applyLayerProperties (object,true,true,true,false,true,true) 

Applies attachment to a light.

We are VERY happy with it, as that means light can be configured to be visible to reflection/refraciton/shadow/alpha/etc etc/ which is great. (actually I didnt test all but artists use it and they are happy so I assume it works 😄 at least visible to reflection/primary visible works from my test)

But it also breaks the native UI. 

We still want that system to work in apiV2 as it greatly extends what vred does. 

For now we have a logic that when we render we apply our overrides/unapply all of them after render using vrFields nodes so as long as v2 let us do that and we have v2 Fields we good. 

Don't bother fixing the UI on second though, were happy with this 😄 

I'm assuming we will have fieldsV2? We are usisng it a lot in abstract script generation to access properties/etc. I don't really want to go via class getXX/setXX logic tbh if I can do it via abstract fields atrs.

Thanks!

[michael_nikelsky]

I think the issue is that you are attaching the attachment to the wrong node. Lights have an internal visualization geometry which already has a geo attachment. So the correct way to handle this would be to get the attachment of this visualization geometry instead and set the attributes there. This should then not break the UI controls since it is still accessing the correct attachment.

I don´t know if there will be a V2 API version for direct field access, as I said it is easy to break something with the field access and things that work in one version might not work at all in the next version. We might think about having some more generalized functions to access specific things like we have for example for retrieving all textures of a material so it is better to have specific request on what you want to do and which properties you want to access. 

[Bob.Bon2000]

Hey

Found the function, 

setNodeVisibilityFlags

Running this with light will do the attachment for me & break UI. - keep it, don't fix it, its a feature in our eyes 😄

As to vrField access, hmmm its a bit worrying, were building our api so it works a bit like maya...

cmds.setAttr("obj.attr",value) 

I don't really want to build an abstraction for each function/method/class/etc/etc that u guys do with object oriented api v2, its nice for dev, but bad for auto generating code/etc... 

Would be great if there was vrField access despite it being dangerous... 

Thanks!

[michael_nikelsky]

I think the compromise for the V2 API would be a syntax like you describe that works on the vrdObjects properties, so basically something vrdObject.setProperty("propertyName", value). This will give you a common interface without the risk of breaking the internals. I can open a ticket for this.

[Bob.Bon2000]

@michael_nikelsky I love it! setProperty/getProperty wop wop! But maybe try not to colide wiht Qt-properties... unless thats what will be used under the hood in which case even better... I could call them directly from c++ maybe o.O 

I've noticed some hints of c++ api in latest docs scattered around... are there any more official news on that / c++ services/etc ?

https://help.autodesk.com/view/VREDPRODUCTS/2026/ENU/?guid=VRED_Python_Documentation_Custom_Interfac...