Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of Lights #17

Open
MeFisto94 opened this issue Mar 17, 2019 · 2 comments
Open

Handling of Lights #17

MeFisto94 opened this issue Mar 17, 2019 · 2 comments

Comments

@MeFisto94
Copy link
Contributor

Currently, XBuf handles lights "wrong", at least on the jme side of things.
First: I don't know if changing the importer or exporter would be better, because xbuf is designed to be jme-agnostic and thus the xbuf files should follow blender conventions.

Current Situation: Export a PointLight, get a Node with the name of the light and the transform which has a light as it's child.
Problem: Lighting only affects that intermediary node and thus the lights have no effect.

Proposal: Add Lights to the Model Root (or the light node's parent, which should be equal, I suppose)

Downsides:

  1. Unclear whether this should be handled in add_relation_raw() in export_all_lights, L445 in xbuf_export.py or in xbuf's LightMerger/LightToGeometryMerger
  2. Custom Properties (UserData), Moving/Animating Lights, Naming Lights:
    In jME Lights don't have User Data or a Name. That isn't that tragic, but if you animate lights, you'd need a spatial with a LightControl (XbufLightControl). This is already implemented in xbuf and adds the light to the model root, but imo all lights should be added there and maybe only when lights are animated, keep the spatial to copy the transform. Or only when the XbufKey is set to use the light control, then keep the spatial, otherwise delete it?

Like: if (!useLightControl) { lightNode.getParent().addLight(light); lightNode.removeFromParent(); }

So based on 2 and the xbuf key, this would be a case for the importer. What are your opinions?

@davidB
Copy link
Member

davidB commented Mar 17, 2019

first hot reply :

  • if change, then it should be on JME importer because it's a consequence of the way JME manage lights and what is affected by light
  • iirc I choose to not hard-code the attachment light to the root because:
    • during the import, xbuf doesn't know the root of the scene
    • to allow user to do some effect like apply light or not some target (same approach as JME)
    • to let the user do that during a post-import phase (like processing user-data, make physics,...)

I need to go back into the code (xbuf and jme) to remember.

@MeFisto94
Copy link
Contributor Author

MeFisto94 commented Mar 22, 2019

during the import, xbuf doesn't know the root of the scene

That's right, I would probably only add them to the model root anyway, as that is what blender does anyway (not affecting other models)

to allow user to do some effect like apply light or not some target (same approach as JME)

That's a good point but currently it doesn't do that at all. Not sure how/if blender could support scene-graph-hiearchies but currently the light doesn't work at all, hence the issue.

to let the user do that during a post-import phase (like processing user-data, make physics,...)

That's true, there it would work, but then the user might need to configure everything through userData to the point where it is almost as much work to hard-code lights generally

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants