Authoring Lights and Static content with Lightmaps

Just curious if the upcoming DOTS Sample project will include workflows/support for authoring Lights and Lightmapped Static contents. If not, can anyone provide a rough ETA?

Thanks!

 

Also very interested in this as well as in DOTS camera.

My use case takes either moving all the lights and cameras multiple times a frame or having a bunch of them (being rendered in a specific order). So I wonder if Pure ECS solution is coming at some point

 

Does this also answer my question or only the topic starters one?

 

I may be completely wrong on this. But I'm guessing lights and cameras have too much dependency with the new SRPs so that it wouldn't make much sense to tackle them into pure ECS until all the other relevant issues (integration between SRPs and ECS) are sorted out, hence the relatively long timeline.

 

That's sooner than I would have expected. DOTS and its heavy use of instancing doesn't seem to go along well with lightmapping UVs from an authoring perspective given the current API. Have you thought about using Volume Encoded UVs? I feel like that would be an easier approach given that the UV map would be independent of the entities being lightmapped.

 

Awesome! Is it gonna be Pure ECS right away or at some point? Would it be possible to set camera rendering order or the render multiple times per frame?

 

Lights and cameras generally do not need to scale like most other entities, so I'm okay with the Companion GameObjects workflow. In fact, I'm doing the exact same thing in my current ECS project (having systems to handle transforms, lifecycles, and pooling of such GameObjects).

So one recommendation if I may: have the workflow be flexible enough to allow extra logic on top of the default lifecycles so that stuff like pooling of the GameObjects can be easily implemented by the user if needed. Pooling is just one example; I'm sure there are other needs for managing the GameObjects in specific ways.

And I'm sure this Companion GameObjects workflow can extend beyond just lights and cameras. It can effectively build a better bridge for transitioning from MonoBehaviour to pure ECS.

 

Does this mean cameras are not going to see the Pure ECS light? Or is it just far-far away from happening, but is going to happen? If not, it seems quite sad.

I am working on portals, that involve some recursive camera render calls. I was hoping it would be possible to just somehow sort the cameras and have them drawn by the camera component system. Otherwise, I guess, I'll get to use a single camera, moving it multiple times a frame to draw all the recursive portals. It just feels slow, but hope it won't be much worse than it would've been if it was Pure ECS. I understand this is a rare use case, and it's not worth devs time at this point.

You may say that I'm a dreamer
But I'm not the only one
I hope someday you'll join us
And the world will live as one

Besides, I can only wonder what games could have created if it was possible to have tons of high-performance cameras.

 

Thank you very much for your response!
I am sorry for the off-topic, but is there a place where I could get more familiar with detailed difference of camera.Render() vs multiple cameras rendering? It's a surprise to me that camera.Render() does more than multiple cameras do... not this exact thing in a loop to render? I'd love to research this topic deeper.

Currently, I render the camera manually anyway, since I need it to render into a RenderTexture and apply it over a portal on each iteration (before any other camera render) so that it was visible by other portal cameras (which do manual render as well). The cameras are disabled, by the way.

I wonder if manual Render of each camera (even if they are disabled and separate) is worse than a single camera teleported or I am just using the wrong approach.

Edit

I think I should get rid of the possibility of the portals to render each other from different perspectives and just assign a camera per portal material and use it with no manual render, but still, interested if (and why) manual Render might be a bad thing.