Effects bleeding into other models

[Keither]

Hey there!
I am just getting started with xLights, and I am having a small problem. I have watched mostly all of the tutorials I can find and still I can't figure out my issues.
First, I am getting a bleed from some models onto other models in the preview. I have checked to see if the channels overlap, which they don't, and I don't think the addressing should have an effect on the sequencing per say.
Also, when I make a change in the layout, I can't get it to show the change in the sequencer. I have tried to quit and restart the program, as well as delete the model from my sequence and re-add it.
Anybody have some insight?

 

[keithsw1111]

Render all. Changes to layout will not automatically trigger sequence rerendering.

 

[Keither]

Render all. Changes to layout will not automatically trigger sequence rerendering.

Hey thanks!
After this fix I now find myself needing to render all at random points. Sometimes the effect doesn't generate on the preview, or it's wonky colored. Sometimes I lose half of the sequencing, and I know it's there so I render all and there it is. I'm way over on the specs required to run the program, I have a beefy gaming PC that exceeds them.
Either way, I am getting by now and thanks again

 

[keithsw1111]

There are situations where you do need it but it shouldn't be often. You may have other issues with overlapping models. I suggest you run check sequence.

 

[Gilrock]

The only time I know of where an effect might not get rendered is when copy/pasting multiple effects. Otherwise it's a render order issue you are seeing which you are in control of changing.

 

[Wolfie]

Gil,
I have noticed lately that using up/down arrows will leave what I call "latent image" of where the effect was and not update until something else in that cell area gets selected. Not sure of slide left/right will as well. I suspect the keyboard movements are not triggering a re-render.

 

[Gilrock]

Gil,
I have noticed lately that using up/down arrows will leave what I call "latent image" of where the effect was and not update until something else in that cell area gets selected. Not sure of slide left/right will as well. I suspect the keyboard movements are not triggering a re-render.

Yes that works the same as a copy/paste. Not sure I want it trying to render every time it changes which row it's on...it would make the key response sluggish.

The thing I would like to see us incorporate is the ability to re-render a selection in the timeline.

 

[Wolfie]

Gil,
I have noticed lately that using up/down arrows will leave what I call "latent image" of where the effect was and not update until something else in that cell area gets selected. Not sure of slide left/right will as well. I suspect the keyboard movements are not triggering a re-render.

Yes that works the same as a copy/paste. Not sure I want it trying to render every time it changes which row it's on...it would make the key response sluggish.

The thing I would like to see us incorporate is the ability to re-render a selection in the timeline.

I fully agree with the laggy result if it did fire a render with each movement. Not what I was suggesting.

However a simple method to accomplish the same end result is when the keypress occurs and a successful move occurs (or delete, or paste, etc), set a timeout trigger for something like 5 or 10sec in a background thread with some id that references the current section. Each key movement resets the timeout with that task id. Then when the timeout lapses it fires a worker process and the section would re-render. Obviously the worker process would need to render the current placement as well as the former location (in the case of delete, or time shifting move left/right as well as current elements and former elements which would alleviate the ghosting). This takes care of multiple moves in a short time and then when the user stops moving stuff for a few seconds, the render occurs. No lag should be noticed by the user with this setup. Now whether xLights has internal mechanisms to deal with this is another story entirely. Yall with the inside scoop would know whether the concept is possible within the architecture currently in place.

I would love (read: serious happy dance) a "Render Highlighted Section". What a time saver that would have been last night Gil. I was working on a sequence that had video rendering on my megatree and trying to time some shockwaves and other effects to it and it kept dropping the video off the tree from the section I was working on and I would have to sit there with it looping that section over and over until it got around to rendering the video on the tree again to see if the timing was right. Drag the effect a little and loop it for a minute or so again. A method for force rendering the current selection would be a great help in this circumstance. So, by all means, please move ahead on this feature if at all possible.

I am sure I was doing something stupid to cause the blanking but I don't know any other way to do what I was doing. It was frustrating nonetheless. I had video from Frozen (Let it go sequence) on the megatree. I used Premiere to re-render the DVD rip down to a square (rather than wide screen) and also reduce the amount of work xLights had to do to process the video. I made it 200px or so square from full HD wide screen. I also took the intro (disney fireworks and castle) and opening movie title ("Frozen") and layered them in Premiere as well to reduce video processing in xLights. That way there was a single video effect that it had to deal with on the megatree. And I was putting effects (mostly shockwave and ripple) on a master (whole display) group to generate effects as though Elsa had thrown her frost off the video onto other scene elements. I don't know how else to do it. If you (or anyone else) has a better way of doing it, I would love to hear it.

I presume the dropouts on the tree are a result of the tier structure and the data manipulation it has to deal with for the video. The megatree (with video) is at the bottom of the list in the sequence, the whole display group is at the top which is where the effects I was manipulating were. So I presume it would see the change on the top and filter down the render tree and finally get to the video which by virtue of being at the bottom gets precedence over what goes on the pixels. And since its a 3min video its got to deal with, I presume requires some data chunking to finally get to the time in the timeline and extract the relevant data from the video for the pixels. So I fully grasp the overhead here.