3d Particles serious lagggggg... Help!

David

Dear friends,

I'm having a show on monday night and my 3d particles are lagging seriously no matter what computer They are playing on.

I've tried everything I've think of. I've noticed the lag over the years but I thought it was because of a lack of processing/Gpu power..

But no, here's a sample video. Can anyone help? I'm runing Izzy 3.0.7 on a MacBook Pro 2018, i7, 16Gb and a Imac 27, 2017, i5, 24Gb.

Gravity x is set at 6

I've had the same issue with this piece runing on 2 gaming PC with RTX 2060

Thank you

David

tomthebom

@David

I find it difficult to help you without some more information: information about the pictures you are feeding into your particle system and the configuration of your particle system.
Can you send a patch or at least a picture of your 3D particle configuration?

David

@tomthebom Hi here's the patch and the png file

Thank you

Forum.zip

mark

@David

I opened your patch and it ran fine for me -- though I only had a preview window, not an external monitor.

I guess I'm not sure what you mean by "lag" -- do you mean "glitches", i.e., very small pauses or?

Best Wishes,
Mark

jhoepffner

@David

I just tested your patch on my computer (MSI with GX 1070 8Go Vram) and it works without problem on a UHD output. I just deconnected FFGL Colorizer and Invert (not on my system)

sommerdi

... in full screen view 3072 x 1920 Retina i feel it looks ok on my MBP .... in Preview it may have laggings ... the izzy load app. 2,5%

msanii

Your patch runs fine on my MBP. Izzy Cycles 516, FPS 60, Load 3.5

DillTheKraut

@david

You use alot of horizontal movement. My experience ist, that these movements often are very timing critical. This means, you have to watch very cearfully over your frame rate chain. All settings from software over GPU output to display needs to be the same frame settings or a multiple of the bevor one.

Secondly, the movement timings manners in the same way in conjunction with frame rate.

You do have a fixed number of horizontal pixels. As an object has to move over these pixels in a certain time, not every pixel row is shown.

Lets try an simple example and imagine a single pixel as an object. This pixel has to move 1000 pixels along in 20 seconds on a 50hz framerate. The pixel is moving one display pixel every frame.
But if you change the speed to lets say 22 sec the pixel would move 45,45 pixels per second. But as we can't show broken pixel, the object pixel has to jump over or stay longer on some displays pixels, instead of move one display pixel at a time.

If you would put this in a shemata where every number symbolizes the time the object stays in a display frame, it would be like this: 1,1,1,1,1,1 compared to 1,1,2,1,1,2 or 1,2,2,1,2,2

The human eye is recognising this as an error in certain situations and this effect is multiplied on large screens, as objects over jumping pixels, jump a longer distance. This makes it difficult to recognise it on small screens sometimes.

Best

Dill

bonemap

Hi @David,

I notice what appears to be dropped frames or a kind of stuttering that is exacerbated if more than one application or processes are in progress while the patch is running. I can see this would be very frustrating and annoying to deal with...

For what it is worth, I have had a go at optimising your patch to run more smoothly and this has included a few configurations, but I have to say as soon as I start any other program or operation inside or outside of Isadora, the frame dropping/stuttering is visible again. As @DillTheKraut suggests optimising to the refresh rate of the output display appears to be a good idea.

These options appear to reduce the problem...

1. Target the frame rate of Isadora preferences to the Hz rate of the output display with Display Refresh Lock 'Off', -The following setting is based on an external display running at 60 Hz. Setting a frame rate of 60fps going to increase the load on your cpu and gpu - a lot- . It is always a trade-off between graphic speed and computer load.

2. Optimise the patch properties. This included, using only one Pulse Generator and dividing the pulse trigger to the 'Counter' and the 'Add' 3D Particles, changing floats to integers and conforming all of the hidden properties between the Wave Generators and 3D Particle input properties. I also compared the 'Virtual Stage' approach to the 'Renderer' approach but I am unsure if there is any difference there. Hiding/collapsing the modules also appeared to improve the situation...

attached is my attempt at optimising your patch..

Gumbs_bonemap.zip

David

Dear all thank you for your input!

@DillTheKraut @bonemap thank you for taken the time in making a detailed feedback!

I didn't quite understand everything @DillTheKraut said but it's very interesting to investigate the movement timings.

@bonemap thanks a lot! there are so many features i have to learn in isadora. I'm very grateful for the optimisation that i'm going to have a look at.

The show went ok, there was really noticeable lag once the particles projected large scale.

Best,

David