Render Taking a Very Long Time

[algerdes]

xLights Version 2020.28. 
Sequence - Little Drummer Boy (2019 xLights Around the World)
Doing a manual render (button in menu).
This normally takes about 2 to 3 minutes (or less) to render.  I just passed the 30 minute mark and the render is still reporting, "Rendering all layers" and the green bar is sitting almost at the beginning.

1.  How can I tell where the render is actually at - in case the report along the bottom of the screen is inaccurate?
2.  How can I track down what is not working?  To be honest, I've never had any problems with render before this.

Note that I have had to bale on the process before (due to this hang).  Before I restarted xLights, I deleted all Little Drummer Boy files and then copied them back in from my safety copy.

Other sequences have come over without a problem, so I believe it is something to do with all the fancy stuff being done in this sequence alone. 

Note that I am using xLights in the 3D mode!

Thanks for any assistance you can give to finding out what is going on, or not going on as the case may be.

[Gilrock]

3D mode has no noticeable effect on rendering.  The truth is there are many threads rendering at the same time so we can't display a single line to text.  If you see a progress bar stop then its rendering or waiting on something else that it depends on.  Not sure why it changed on you cause I've been working other things but they can't help unless you provide a sequence.

[dkulp]

If you package up your version, I can try and take a look and see if I can reproduce it.

It surprises me slightly as this is one of the sequences I've been using as a benchmark for the performance work I've been doing.   It's very "core/thread heavy" so it pushes the threading harder.   The Greatest Showman sequences was more video heavy which pushed the video parsing and less core/thread so the drummer boy sequence is interesting for benchmarking/profiling a different set of things.     For me, 2020.24 rendered my mapping of drummer boy in about 77 seconds on my machine.   2020.28 has it down to 65 seconds. 

[algerdes]

What files do you want Gil?  Glad to send along any files you need.
BTW - I didn't suspect the 3D.  Just the environment I am trying to live in now.
(As stated, the other sequences are working fine so far in the 3D environment of 2020.28.)

I backed down to 2020.26 just in case (it was working on it a couple of weeks ago).  I'm getting the same with it, so I am suspecting something has gotten into the sequence itself.  Just can't find the bug/error/mistake/missing whatever.

My show folder (working) is C:\sequencing\2020\LWW Christmas Street 3D\.
For some reason the directory shown at the bottom of the screen when I'm rendering is:
D:\Sequencing\2020\LWW Christmas Street 3D.  This is my storage/safety location on my NAS.
I've gone through and told xLights that I'm using the show folder for everything.

Check Sequence was reporting that the shaders in the sequence  were pointing at another location, "not in the show folder."  I corrected this.  Still no joy.  Other than the fact that I have all of my controllers offline (set in xLights), Check Sequence comes up clean now.

The xLightsProblem.zip file is attached.

[algerdes]

Thanks to both of you.

Dan, I've packaged and attached here.

[algerdes]

I just noticed that the 2 "MH Star 50 1" and "MH Star 50 2" are not showing any green in the progress bars.  Interesting as they have plenty of effects against them.

[dkulp]

There is something wrong with most of your polyline models.  For example, if you click on "East Twr Parapet" on the list, nothing is highlighted in the preview.   Looking at the coordinates, they are WAY off the preview someplace.     That's the main issue is that the polylines are way out someplace so the "Per Preview" render buffer style is generating a gigantic render buffer which is causing a bunch of things to not render properly.

I would suggest deleting and recreating those models.   

[algerdes]

Thanks.  I'll take a look at that now.
(Definitely nothing I would have found.)

[algerdes]

Holy Vacation Batman! Talk about long distance!!!

I was able to find the parapets by stretching the screen across both 27" monitors, then zooming out till the props would not show (too small). Came back in one click, and there they were - way the heck to the other side of the view.  I have no idea as to how they got all the way out there.  Was there any wayward calc that took place?  I don't know. For now, I'll just chalk it up to FM.

I am having trouble getting them to allow me to move them inline with the Castle Towers.  There is a note in my book that polylines may be a problem at this time.  Is this still so?

If I stumble upon the ability to move the polyline forward and back, I'll let you know.

For now, render takes only a minute and a half. 

Thanks for both of your help.  Most appreciated.

[algerdes]

As a followup.
Once again, the polyline "parapets" have gone on walkabout.  I have no idea as to what is causing this behavior, but this time I was prepared.  I created an xmodel for each of them (since they have different starting points) and made note of the starting Universe/Channel for each.  I then deleted the old models and imported new. 

This works.  I just don't know why they go from the main area off to somewhere thousands of digits out of the screen.

If you ever figure this one out, please let me know. 

Thanks for all your help.

[Gilrock]

I've never seen a model move without operator input.  And when you do try to move the handles if you are near parallel to the move axis it can shoot the models way off into the distance real fast because it has trouble finding the mouse intersection.  Like if you are moving along the blue (Z) axis it uses the Y/Z plane intersection so you want the screen rotated a bit so Z isn't pointing directly into the screen.

[algerdes]

I'll keep a very close eye as we move props around.  This year we are definitely changing everything, so it will be a good test.

Will let you know what we find, if we witness it again.