Color wipe over existing effects

[Phrog30]

OK, thank you Gil.

Sent from my Pixel using Tapatalk

[dkulp]

I don't think we have any plans...most of the time none of us know what others are working on until maybe a couple days before it's done.  On rare occasion one of us may mention an idea before we do it.

Ummm...  it IS on my plan for sometime this year, but it's going to take a while to get there.  My first priority is getting the SubModels in Groups and Groups and Groups stuff a bit more solid (mostly works in .56).  At that point, the definition of what's in a "Model" should be more stable (unless someone else has more ideas for ways to muck around with groups).   After that, it's updating the render engine to render the entire "tree" of dependent models, but only for the nodes of the target model, when an effect changes.   That needs to be done first.   The last step is the blending between, but that's also the easiest once the stuff above it is done.

The other consideration I'm noodling on while rethinking the rendering is a new model type that is similar to a group, but instead of applying to a buffer representing all the models, it would apply to each model in the group individually.   I'm not quite sure how to get that to work yet without killing rendering performance.   Plus, its something that would have to be a completely different group "type" so not sure what to call it to differentiate it.

Basically, I DO have a bunch of rendering engine changes my brain is working on.   Just not sure when I'll get around to them all.

[Gilrock]

See that was all news to me which was pretty much my point...lol.

[dkulp]

2.  Is it possible to share the steps necessary to add the code like Matt did?

Here is the full diff for what is needed.   That said, I believe Matt backed out of it and went back to normal because you end up having to hit "Render All" ALL THE TIME.   If you change a setting on an effect, it renders over what is already there so you cannot really see the change.   If you delete an effect, it won't clear the area.   Etc....   Matt found it too annoying. 

Code: [Select]

diff --git a/xLights/PixelBuffer.cpp b/xLights/PixelBuffer.cpp
index 2a395f5..a831baf 100644
--- a/xLights/PixelBuffer.cpp
+++ b/xLights/PixelBuffer.cpp
@@ -109,7 +109,7 @@ void PixelBufferClass::InitBuffer(const Model &pbc, int layers, int timing, bool
     {
         model = &pbc;
     }
-    reset(layers, timing);
+    reset(layers + 1, timing);
 }
 void PixelBufferClass::InitStrandBuffer(const Model &pbc, int strand, int timing, int layers)
 {
diff --git a/xLights/Render.cpp b/xLights/Render.cpp
index 2c36e8b..1be3a6b 100644
--- a/xLights/Render.cpp
+++ b/xLights/Render.cpp
@@ -524,11 +524,11 @@ public:
                 if (frame >= maxFrameBeforeCheck) {
                     maxFrameBeforeCheck = waitForFrame(frame);
                 }
-                bool cleared = ProcessFrame(frame, rowToRender, mainModelInfo, mainBuffer);
+                bool cleared = ProcessFrame(frame, rowToRender, mainModelInfo, mainBuffer, -1 , true);
                 if (!subModelInfos.empty()) {
                     for (auto a = subModelInfos.begin(); a != subModelInfos.end(); a++) {
                         EffectLayerInfo *info = *a;
-                        cleared |= ProcessFrame(frame, info->element, *info, info->buffer.get(), info->strand, cleared);
+                        cleared |= ProcessFrame(frame, info->element, *info, info->buffer.get(), info->strand, true);
                     }
                 }
                 if (!nodeBuffers.empty()) {


[Phrog30]

Thanks Dan. It sounds like I will just leave it alone. I appreciate your feedback.

James

Sent from my Pixel using Tapatalk

[Gilrock]

One thing I was really wanting while sequence last month was ability to select a small section and render just it.  I guess that wouldn't be needed if you implemented some of those ideas because it would theoretically always be up to date.

I've wondered if we could create something like a "model container".  It could be used mainly for organization where you want to put a bunch of models into sort of a folder.  A container would not be a renderable object it would just pass the effect down to all it's members.  Containers could be nested also.

[flyinverted]

I often will put an effect on a model then remove the effect.
The effect will sometimes show on the single model in that is also part of the model group until I re-render.

This is just one small example of where a manual render mode would be great.

Just as we often select a small portion of a sequence to play. I really only need to render that small section I'm working on as well.  How bout a quick render option where +X and -X seconds are rendered on either side of the selected effect.   

[dkulp]

I've wondered if we could create something like a "model container".  It could be used mainly for organization where you want to put a bunch of models into sort of a folder.  A container would not be a renderable object it would just pass the effect down to all it's members.  Containers could be nested also.

"Model Container" is a good name for this and is what I was trying to describe. 

The complexity comes in how to "pass it down".   There are several options I've been bouncing back and forth in my head:

1) Make the container a renderable object so it WOULD get it's own render thread and for each frame, it would render the effect on each models buffer, etc... The complexity of this is around the mutex locking.  Right now, the rendering of a model is on it's own thread so it can avoid a bunch of locking scenarios as it knows it's the only thread rendering that model.   As soon as another thread (or many threads if in many containers) could also render to that model, I need to add much better locking.   Also, the effects that need to save some state from frame to frame may need to make sure the state is per-thread or something (or have separate RenderBuffer objects for each model on the different threads, but that then sucks up memory...  64bit windows anyone?).

2) At render initialization time, copy the EffectLayers (or really just the pointer to the EffectLayer) into the models RenderJob object.   If the "Container" is before the model, they are copied to the bottom of the models stack.  If it is after, it is added above.  Thus, when the model is rendered it has ALL of the layers it needs.   This is simpler for the rendering engine changes.  HOWEVER, it won't work well with the existing model groups as the rendering "order" of the container wouldn't be considered at all.

I WANT to do #1, but I'm semi-scared of the instability I'm going to cause by going that direction.     Luckily it's only January. 

[arw01]

What about rendering it all as fast as possible, and then using some convention to keep only what you needed?  Why care if you can store the render that might be wrong if you can get it done faster and discard it for the one that is proper when you know what you need from working through the layers.

If you spend less time checking ahead of time and just doing and tossing can that open up a different direction to go?

Can you have a thread always rendering what is dirty while it's happening and not burden memory or the processor?

[Gilrock]

Yeah I would like to help work on making Windows 64-bit.  I forget which of the 3rd party libraries were causing us issues.

Regarding rendering a "container" what I thought might be an issue is the Render Style.  I guess you would be stuck with every model having the be the same like Default or Per Preview.  I just know for some of my sequences I had sections that looked better if I just copied the effects onto every model instead of using it at the group level.

[dkulp]

I thought you guys were flagging effects as dirty when they changed?  Or is the issue the recursion down the groups and other effects being dirty too?

When an effect changes, we tell the Model that the effect is on that it is dirty from the starting time of the effect to the ending time (if the model already has a dirty area, that area is expanded to include those times) and then a RenderJob is created and pushed onto the job queue to render.    At this point, ONLY that model gets marked dirty and re-rendered.   This doesn't propagate to other models that may "depend" on it.  For example, changing an effect on a group will re-render the group, but if a model is supposed to be rendered after the group and it has effects that would override the group effect, it doesn't get rendered and thus what is displayed is technically wrong until a complete re-render.   Likewise, if you delete the overriding effect on the model, it doesn't tell the group to re-render to fill in the data that was then deleted.   

So yea, that all needs to get fixed so that what is displayed is always "more or less" correct. (*)   Once that is done, then getting the blending between models can proceed as we can clear the channels for the changed model and then render every model that depends on those channels and have the blending work.   

(*) effects that depend on a Random number may not render correctly even with these changes.   If we have to start rendering in the middle of an effect, the previous data based on the randomness is not there and thus not usable.   For those, we can only get complete "smooth" results by completely rendering.  This could be fixed by seeding a random number generator with something tied to the effect at init time to get it into a known state and iterate, but there are a lot of effects that would need to be updated.   

[dkulp]

Yeah I would like to help work on making Windows 64-bit.  I forget which of the 3rd party libraries were causing us issues.

I keep wondering if we even need to keep the 32bit version around, or maybe just provide 32bit versions of the stable builds or something.  Since Windows requires separate builds for 32bit and 64bit (Mac has fat binaries that allowed both to be built at the same time and in the same executable) it's definitely double the work for Sean to have to do both.   

For the libs/dlls that we keep in git, I think it's just a matter of obtaining the proper libs, adding them to a new lib/windows64 dir, and updating the build scripts to look there for 64bit versions instead of lib/windows.   wxWidgets is slightly more complicated for you/me/Kieth that would "always" be building the same version, we could keep it as is.  For Sean that may need to build both 32bit and 64bit, I don't really know how he'd have both at the same time.   

[arw01]

Why would a 32 bit version be needed, are we talking pre windows 95 here, or how old of hardware, 5 years, 7 years, 10 years?

Make a hard line in the sand and say anything that is not 64 bit windows after version 2017.5 will not be updated in 32 bit land, we have moved on.

[dkulp]

1.  Are there any plans to implement blending in a future release?
2.  Is it possible to share the steps necessary to add the code like Matt did?

I've managed to complete most of the work that is needed for much of this.   For anyone that would like to experiment with this and can follow all the instructions for building xLights, the latest code on master is very easy to update to support the model blending.   All you need to do is edit the SequenceElements.cpp file and search and replace the 3 occurrences of "supportsModelBlending = false;" to set it to "true" instead of false.   At that point, effects should blend between models based on the normal blending modes.

Most likely we'll make this a per-sequence setting exposed someplace in the Sequence Settings dialog.   For sequences made in prior versions, we'll default this to false so things will render the same.   For new sequences,  we may make this "true".  That will simplify trying to fix all the existing effects to render the same.

Feedback is welcome.  Thanks!