Graphic help needed

[jacque]

Regarding my own code, I remain unconvinced that it is not a bug in LC, but saying it isn't faulty when there seems no logical reason why a default rectangle should be added on the second click when it works as expected on the first click.

Just another way to explain it:
When you create a new control from script, LC gives it some default properties. Your handler then adjusts the defaults to make the control look like you want. The default shape for a graphic is a rectangle.

When you refer to a control by name, LC has to search all the controls for a matching name. It starts with the first one and keeps looking until it finds one with the correct name. Once found, it applies whatever you've scripted to that control.

On the first click of the button there are no other graphics named tLine so the properties you set are applied to the first graphic. On the second click, LC searches through the graphics in numerical order until it finds one named tLine, which is still the first one, and sets the properties on that one. As long as all your graphics have the same name, LC will always stop looking when it finds the first one.

There are three ways to avoid this as posted above. Another way to fix the problem is to refer to the last graphic, which will always be the one most recently created. LC won't scan through the earlier ones in that case, it will use the one you intended.

Code: Select all

set the style of last grc to "line"

It's usually better to just give each graphic a unique name so that you can refer to it later directly if you need to in other handlers.

[jmburnod]

Hi ajperks,

I prefer to understand how things work rather than copy and paste.

Yes you're right.
No it is not a bug, as sparkout said in his first post, there is a logical reason, your code create the second grc with the same name as the first, LC take the first grc called "tLine".
I hope this help
Best regards
Jean-Marc

[ajperks]

Thank you all. I can understand the issue now. I have noticed the naming aspect as the items appear in the Project Browser.
I have since progressed with a circle and no issues, having adapted the working code supplied by Sparkout.
The trigonometry part is the easiest, for me, and I hope to have the lines (Rays) springing from the left (Zero point) of the circle out to the division points around the circumference of the circle.
I couldn't think of a way to intersect the Rays to the division points around the circumference, other than calculate the ray length and draw them in isolation. Perhaps they won't meet the circle due to rounding errors, but 0.5 of a pixel won't worry me.
If I actually get this silly thing working, my big challenge will be finding ways to speed up the calculation. It might be better to save each iteration as a JPG and string them together as a video.
Optimisation tips would be welcome. Is it better to do trig calcs as the rays are needed or use a look-up table for the end points of rays after calculating all of them?
Thanks again, progressing nicely.

[jmburnod]

Hi All,
I played with the effective points of an oval grc to create rays

CircleAndRays001.zip

(8.48 KiB) Downloaded 282 times

Jean-Marc

[ajperks]

I am finding a wealth of leads to info in the dictionary now, with your stack. I can see our different approaches in code that seem to lead to a similar result, and yours gives a fuller picture of what is needed.
My rays don't emanate from the central point but like the numerals on a clock face, depending on the result of a calculation, they are joined like 2 & 3, 3 & 7, 4 & 9 but not predictable. That isn't important, other than getting the points of two relevant numbers.
The deletion of the graphics was useful to know. I will be reusing the lines drawn with one set of calculated coordinates with a changed set, so the build-up of the patterns is, hopefully, more interesting.

[dunbarx]

Glad you are getting along.

But if you set the points of the various lines, so that the first point of each is common to all, then those lines will radiate, er, radially outward from that single point. Such as:

'200,200"
"300,300"

and

"200,200"
"100,300"

etc.

You will have to calculate the second point of each, so that the lengths of each line are the same.

Craig

[ajperks]

Hi dunbarx,
Unlike the hands of a clock where the lines radiate from the centre, my lines run from peripheral points to other peripheral points.
I would gladly show you pictures, but that hasn't been switched on for me.
Take one line for example. It might be calculated that a line forming a pattern sequence must run from number 3 (on a clock face) to 5. Apart from the possibility of symmetry, where the pattern is repeated by mirroring the top half to the bottom half of the circle, there are no repeating numbers. In reality, there may be hundreds of points (clock face numbers) around the circle so a dense pattern of lines is created. A few numbers like 0 to 11 hardly makes a pattern, but I have to start from somewhere as I develop the code.
I couldn't find a way of dividing the circumference (like clock numbers do) and sending a line from one number to the other. Remember, the lines do not cross from one half of the circle to the other half. 0 to 6 is one half, 6 7 8... to 0 is the other half, usually.
I am about to explore 'effective points' if I can understand where they are and how to find them.
Before that, I was planning on using Trig to map the number location.
Trig works perfectly but will be slow to process. There is a Sin & Tan calc for every peripheral point...
If anyone knows how to specify the peripheral points so effective points become useful, please let me know.

[SparkOut]

If I am not mistaken, a circular (regular oval) graphic has 360 effective points, thus you can have one point on the circumference per degree of arc.
I am not certain what you want to do, but I can draw from one point on the circumference to another using the following script:

Code: Select all

on mouseUp
   put the number of graphics of this card into tNum -- just to use as an index to provide a unique name when a new line graphic is created
   put random(180) into tP1 --pick any point in the first half of the circle
   put 180 + random(180) into tP2 --pick any point in the second half of the circle
   --that's just to give a bit of separation in case the random values would otherwise be too close together
   JoinPoints tNum,tP1,tP2 --create a new graphic with the index number, and join the points
end mouseUp

on JoinPoints pNum,p1,p2
   lock screen -- to stop the default rectangular graphic being shown until the style is set to line and the points set 
   put line p1 of the effective points of graphic "myCircleGraphic" into tPts --get the points relating to the position of the first position on the circumference
   put cr & line p2 of the effective points of graphic "myCircleGraphic" after tPts --get the points relating to the position of the second position on the circumference, and create a two line list of points to be assigned to the new linking line graphic
   create graphic ("tLink" & pNum) -- create a new graphic with the name tLink plus the index
   set the style of it to "line" -- change it from the default rectangle style
   set the points of it to tPts -- the list of points created is applied
end JoinPoints

I am not sure how speedy it is compared to processing trig, nor how speedy you need it to be.

[dunbarx]

Sparkout.

I never actually tried this before. but the number of lines (at least for me) of the effective points of a newly created circle graphic is 352. Odd?

ajperks.

As Sparkout essentially said, you are looking for chords of a circle. The 352 notwithstanding, these can be referenced pretty close to degrees, which is pretty fine resolution.

Craig

[ajperks]

You seem to have solved my problem beautifully, Sparkout.
A quick test seems to have calmed my worry that 360 divisions might be restrictive. In reality, even a 4K screen is unlikely to show greater detail than 360 points can resolve.
I looked to see what happened when mathematically the answer was not an integer. There appears to be no rounding, just the fraction is truncated.
Obviously, in practice, accuracy isn't a real issue when drawing lines because it comes down to pixels.
It may be that every 2 or 3 or 4 divisions might be the optimum density of lines and that can easily be managed.
I am glad I got diverted to something quite different because whilst I would have enjoyed brushing up on the Trig, I can see that it was going to be the wrong solution, in every respect.
Thank you Sparkout and long live Livecode.
Happy bunny.

[dunbarx]

I said:

I never actually tried this before. but the number of lines (at least for me) of the effective points of a newly created circle graphic is 352. Odd?

Not surprisingly, the number of the closest pixels to the ideal do not always map to the grid perfectly. Fooling around with the shape of such a control gives anywhere from 356 to 360. I never found more than 360, which also makes sense.

Craig

[bobcole]

A small (default-size) circle shows 352 points.
Select the graphic object and use this code in the message box:

Code: Select all

get the effective points of the selectedObject;put the number of lines of it

By increasing the size of the graphic to 600 high and 600 wide, a large circle shows 360 points.
FYI,
Bob

[SparkOut]

That would make sense as I was working with a graphic 600 x 600 for testing.
I am going to presume (dangerous, I know) that a smaller graphic has not enough room to fit 360 unique effective points using only integer pixel values, so the engine filters out any that would overlap.

[SparkOut]

As a game, I made a stack with a default size circle (regular oval, 120 x 120px) with default name "Oval" on it and another any old line graphic with a name "fakeOval", plus a button that had this code

Code: Select all

on mouseUp
   put the effective points of graphic "Oval" into tPoints
   repeat for each line tPoint in tPoints
      put item 1 of tPoint + 140 into item 1 of tPoint
      put tPoint & cr after tNewPoints
      set the points of grc "fakeOval" to tNewPoints
      wait 10 milliseconds with messages --just to see the shape as it was being constructed
   end repeat
end mouseUp

The effective points list did indeed contain 352 lines at that size, and running the script showed the fake oval being drawn next to the real one. It did indeed make a complete circle. Changing the size of "Oval" to 80 x 80 the effective points had 248 lines, 40 x 40 had 144 lines. Again making a circle each time - so the effective points (of a circle) seem to resolve to 1 point per degree of arc where there is sufficient room, and with some thrown away when there is not enough space to cram in points that don't have a sensible change in value.

[ajperks]

Whilst far from complete, also the symmetry maths is wrong, I have progressed to something that can be seen.
All due to the amazing help and support from you guys.
Things still to do:-
For the second half of the display, 180 to 360, it needs mirroring vertically so it is a cardioid, not yin Yan.
You may notice a freeze like state after the lines are drawn. If you watch the Project Browser, the lines graphics are slowly added and something else I can't fathom is also being processed, long after the lines are drawn. Any ideas?
The basic shape is not a full Mandelbrot, of course, but when I get to the real maths I hope that will change.
The single iteration must be replaced with a continuous display using a different multiplier (I used 2 for simplicity). For each iteration, the original lines must be erased, one by one as new lines are drawn. A moving swirly display like a pit of writhing snakes should appear.
With each change of multiplier, the line colour changes. This should cycle through the whole colour pallet in a gradual change of tone.
What do these shapes sound like? As the density and colours change, so does the frequency. The intersection of lines generally could be individual notes. Perhaps it might be the Dr Who sound...

AJP mandelbrot.zip

Mandelbrot so far

(10.75 KiB) Downloaded 283 times

Any constructive comment would be greatly appreciated.