Digital Workshop

Hi Larry,

I think that both initializing time and animation speed may be solved if the script can (1) create the array for the entire 6400 "pool" of dots, then (2) every 100 ms randomly select a new subset of, for example, 40 (if set up as a variable, then this number can be varied to test a range of values until the "correct" one is found) to change, repeating this every 100 ms with a new random subset. 400 randomly chosen dots changed per 1000 ms but done as 40 per 100 ms.

If the initialize time cannot be reduced, maybe a progress bar can be used initially while the page loads, another way to pre-load, or something like that.

Kind Regards,

Stephen,

What is required as an initial page or view? Random. or checkerboard?

The simple solution, even if random is required, is to do something as a Pre-Show action and have a Welcome Frame with a 'Start' button (to hide the Frame).

The script to handle the objects within an array already exists for both the mini-frame version and the drawing version. You'd need to feed the polygons in to the nested FOR loop in-place of the other objects BUT Opus appears to have a problem with the children of vectors and I'd suggest importing each vector independently rather than duplicating if you want to avoid issues with more advanced scripted solutions.


As for timing, the initial display of the 6400 polygons should take a fraction of a second. The initial noise generation is a balance between script execution; screen refresh and illusion. The previous script will take 1 second to change 400 dots or 6.25% of the polygons. Of course on a white background, the visual appearance will be about 3.125% of the dots changing per second. Again, using the previous script this is possibly reduced further because the polygon is drawn randomly on each iteration and thus the same polygon could be drawn 400 times in a single second.

Throw in some logic like just changing polygons to black to start and using a shuffle rather than random pick will speed up the appearance of noise or hit the ground running and hard code the initial colours for instant noise and then just focus on your 400 changes per second.

Mack

Larry,

I don't think there is a requirement for initial view, though the random initial pattern would be preferable. The issue is how long the user would be waiting while the page loads, what else can be displayed (for example, progress bar) while it loads, if no other solution.

Mack,

The current script:



The earlier script you are referencing follows (below), but I am not sure how to integrate the shuffle, etc. into the current script (above):


Thanks for these suggestions.

Kind Regards,

Here an Opus pub attached, which is another proof-of-concept. 'Yes' Opus can handle the 6400 small squares and change the color for the subset required -- and run at a good pace. Organization is 80 Vector columns, each containing 80 polygon squares. I took some care in the layout and spacing, however it is not perfect and can be improved upon.

Note 1. I simply pasted in Mackavi's short script (which was designed to operate on 1600 Vectors of 4 polygons each). I changed the arguments for the random commands to 80 and 80. The FOR LOOP runs through 400 times. A few other minor mods.

Note 2. There is NO LOGIC for preventing the two random(80) statements from duplicating values for 'a' or values for 'b' (that is, selecting the same square more than once in a cycle). Also, I did not bring in any of Mack's routines for better randomization... via shuffle logic, etc.

But, at face value you should have confidence that it can be done and achieve good speed. My core duo CPUs ran at 46% to 56% for this.

Hi Larry,

Thank you for this interesting version. Yes, it appears that Opus can handle the number of objects and animate them. And, looking at the checkerboard initial view, I realized that it probably needs instead to initially display as a random pattern.

This new animation needs a smoother change process in order to meet the "standard" for dynamic visual noise. The animation needs to be more like stars twinkling fairly quickly. (The previous Opus script from Mack produced an animation with smooth change, as required to replicate the dynamic visual noise "standard." However, it wasn't fast enough. His mini model animation completely met speed and effect, but on a smaller canvas. Replicating this on a 6400 dot (or 1600 2X2 vectors, with 8X8 dots) canvas in Opus Pro would be ideal.)

So, I was trying to figure out how to combine the 2 scripts suggested by Mack (see above) to first pool into an array all dots (6400), then randomly select a subset of these for changing every 100 ms. Final version needs to be smooth and change at the speed required of the "standard."

Meanwhile I've been trying to get my drawing program to create all of the WMF vectors directly in that program to then export, for eventual import into Opus. But, that program doesn't have a multiple paste (and offset) feature. The result is that this would require constructing the 40X40 (since these are 2X2 of 8X8 squares) manually, a difficult task at best (1600 copy, offset precisely and pastes). Still trying to figure this one out.

Good progress which indicates that Opus can do this task with the right vectors, script.

Kind Regards,

I must have gotten lost in the thread, and was going according to your early post which I interpreted as 'make change' and then pause to make the next changes for the subset at one second intervals.

In any case, it is simple. I moved the wait() back to inside the while loop. Mainly, I set the FOR LOOP to a small number, 20. And removed the function calls.
You should:
1. Replace the current script object's code with the following.
2. Set the page variable, Wait_ms, default value to 20 (or some other number below 200).

Hi Larry,

update

I set up a single vector in the drawing program with all 6400 dots inside and exported as WMF.

I've imported this single vector with all 6400 polygons into Opus. I'm attaching the IMP.

Maybe it will be easier to use.

I'm guessing that it will change the script to eliminate the second "child" (b)?

When I tried this script, modifying it from "this" to the vector's name (and eliminating the second "child" b), I get an error message: Wait_ms not found.

Does something else need to be declared?

Kind Regards,

I created all the objects within Opus. To build the 'master Vector', I just selected 4 polygons and duplicated to get to 16. Then I duplicated Vector1 4 times. Then I dragged Vector2's 16 polygons into Vector1. Repeated the 'Insert into' for the remaining 3 extra vectors. That left Vector1 with 80 polygons.

I employed a few tricks to get alignment and spacing of the polygons, did renaming of all 80. You might guess I next duplicated the Vector. At that point, I moved one polygon and shifted the whole set -- to make White the topmost polygon vs. Black in the first Vector. The rest was duplicating Vectors. (I set my Opus Preferences to 'offset' only across -- and I changed the amount of offset depending on how many Vector columns I duplicated.)

Hi Larry,

update

OK. If I use the new script with your dots, change the timing to wait (.01), it is definitely starting to look like the "standard" animation.

When I try a similar script modified for the correct object names in my IMP (the IMP with the frame, 1600 16X16's, posted above), I can't get it to run.



Kind Regards,

Okay, we have 3 different models (.IMP pubs) going on now?

So to your question about using my 80 x 80 grid's script in your 'single Vector, 6400 polygons' version --Yes. That was set up as a Page variable in the pub I created. It allowed you to type a number into the Text Input box, to play with the delay/timing. You would be okay, given the latest developments, to remove it from the script and skip it by using constants.

- - - - - -
Replying to your latest post, I think you are using Mackavi's version here... ?

Change code to the followingI did not download anything today, so may be I have this wrong. As Mack said earlier, (the beauty of this method is) we do not need to know the object names, only need to pay attention to what is the Parent... in this case I think you have Frame1 or maybe Frame_1?

One thing THAT WILL BREAK IT is this -- you should not have any other objects inside that Frame. If you do need something in there, you need to make sure it/they are higher in the organizer than any of the Vectors, and you have to have the correct limits for the FOR LOOPS (which seek out all the children).

Hi Larry,

updated

So far, your new script in your IMP works.

I started from scratch, tried to duplicate your design: began by importing one vector with 80 black polygons, duplicated across the canvas until 80 columns, framed all, used the script that you suggested above that works in your IMP.

Working better. But not quite there when compared to the demo's that replicate the "standard."

I'm attaching this latest IMP. Maybe you can suggest a way to improve it?

Kind Regards,

I think you either need to start with a checkboard pattern, or accept the start-up time it takes to 'seed' an initial random pattern. (or create the random pattern in Opus Editor manually).

Here is YOUR pub, DVN1.imp, modified to generate a random pattern on launch. It takes 8 to 10 seconds. That can be shortened somewhat (since I did ~3 loops).

The rest is a matter of playing with the CHUNKS (how big of a bite the Loop handles), and the TIMING (the wait delay).

What I've discovered is that if you do not start with a static ~randomized pattern, or at least a checkerboard -- the display is not so satisfying to begin with.

So here is a test Pub with TWO Pages.
The first page generates its own INITIAL random pattern. This takes time... approx. 8 seconds or so.
-- I have added code to save that 'pattern' to a File.

The second Pub Page SKIPS the on-the-fly initialization routine. Instead, it LOADS the ~random pattern from a File. (you need to run the First page to generate that file at least one time).

This Pub takes yet another approach to the Page structure. Instead of using Vectors/polygons, it uses a Text Object. The good news is that it is very fast at runtime. The bad news is that the visual effect seems a little jittery. I doubt that can be solved, but then again it is early -- I just have not looked into that 'jitter' issue. One trick might be to manipulate Selection Style, specifically backgroundcolour for the text. Then one could use a monospaced font and perhaps get stable positioning. You'll understand what I mean when you see it.

The "text based" structure is certainly more easily managed.

Hi Larry,

Thanks for these.

Having a temp file for "pre-loading" is an interesting concept. I can experiment with them.

Kind Regards,