On 04/10/2010, at 9:44 PM, Mehmet Akten wrote:
Hi, thanks for the tips, learnt a lot. I would say Case 1 is solved,
but still stuck on Case 2 :)
(replies below)
On 4 Oct 2010, at 08:31, Alastair Leith wrote:
also added a dummy input to smooth the execution (sets the Viewer
fps value too)
wow I don't understand the significance of the dummy input. Without
the dummy input it doesn't work for me at all! It doesn't just
smooth it, it makes it work! how does the dummy input make it work?
It's not actually being used anywhere. A JS bug?
It didn't work without it for me either at first but then when I
removed the noodle, it still executed — just a bit jerky.
A good trick is clicking on the JS patch in the editor to force
another execution, if something happens, you know you've got a 'dead'
patch.
A simple Log() statement showed that the update function was
getting called every frame. I have to emphasis I would NEVER be
able to use the JS patch effectively without the Log() statement to
debug/examine it. (Used to do it manually but Log() is better).
Can't recommend it enough, (even to a seasoned programmer like you).
I didn't know about Log, it sure has changed my life now for
debugging JS. I see the log goes to the console, where there is
always a bit of a delay. Is it possible to see the log output
directly in QC in realtime without switching to debug mode (which is
super slow).
See my other email about Graph Foundation Log
A few more edits were enough to get it going but at this point I
want to observe that putting a JS patch inside an iterator and
having each iteration contribute to what seems to be the unified
structure (data), is a real eye-opener to me. I seems kind of weird
and I'm not convinced it's all above board yet ;-)
I'm not suggesting this is the best way to do it, just the solution
that I came up with. Feels hacky to me too.
See following answer.
Global structures across JS patches aren't allowed so that doesn't
explain it… must be the QCs implementation of JS patch inside an
iterator.
Mousing over the Struct_Out port I created shows the 10 items
despite the absence of a JS loop, can I say weird one more time?
Not sure which bit surprises you here? The way I see it data is a
global array and every iterator loop data[iterator_index] is filled
with data. So in the end data contains the data for all of the
objects in one array.
Well this depends on whether you conceive of the JS patch inside
iterator as one patch or n patches. If it is n patch instances (how I
was previously conceiving it and anything else in the iterator), then
you have global variables across JS patch instances, which you can't
do outside an iterator or across separate JS patches inside the
iterator. I just checked that to be sure.
A note from the QC team will clear this up no doubt.
To me JS outside the iterator or Kineme Structure Render patch is
more straight forward but I appreciate you are attempting a OOP
approach so I'm interested to see where you go with this, please
keep posting!
I didn't know about the Kineme Structure Render. Is that the GL
Structure Render? I'll look into it, definitely looks interesting.
It screams compared to iterator on Leopard (me :/)
Anyhow even using an iterator to display the structure the
following comp canes it for performance:
For me:
1a gives 40fps @ 1000 and 9fps @ 5000
2a gives 16fps @ 1000 and locks up @ 5000 :) (after a long wait I
get 3fps).
Did you get better performance out of 2a?
Heaps. I get:
1a gives <1fps @ 50 with almost lock-up and >10 secs to stop comp
2a gives 3fps @ 1000 and 3 sec to stop comp (with Log()s removed)
Taking the **** Initialise **** Logs out made comp start in a second
or two @1000 iter's as opposed to 1:05! (that's >1 minute btw) to get
the first frame of moving cubes. Also 2a has extra overhead
(theoretically) in these two lines which I commented out:
start = true;
if (start) result.Start = true;
Doesn't seem to effect fps much though and I'm sure shinking size etc
doesn't even come into it from my comparisons.
Always good to comment out Log()s when done playing; inside loops they
can really sap performance quickly.
Also I noticed in 2a they were gradually getting smaller and
further, was that intentional? I changed it to the same behaviour as
1a so the fps comparison would be fair (drawing same number of
pixels in case fillrate was an issue with lots of cubes)
Yes, it turns a bunch of squares into a galaxy if you run it long
enough!
I think it makes sense that 1a would be faster. There is only one
loop (the iterator) which cycles through, updates and draws. Whereas
in 2a there are two loops, one in JS (for the update) and one for
the iterator (the draw).
Cause I'm on Leopard my intuition is exactly the opposite. I guess
this test is a great proof of the optimisation of Iterator patch in
SL / QC4 under ideal conditions.
On 04/10/2010, at 6:36 AM, Mehmet Akten wrote:
ah thanks yea, that should be d.mass , not mass.
also it should be pos += vel / mass, not pos = vel / mass. (i
haven't slept much this past week).
So that explains the disappearing.
It seems the update() is called only once per run. Even though in
debug mode the JS patch is flashing red every frame, if I set pos
to random every frame, it still doesn't move. So I need to make it
get called every frame some how. Maybe that isn't too complicated,
then there is still the Case 2 :)
P.S. I've pulled this thread in from the Quartz list to the QC list.
MSA Visuals Ltd.
Unit 107 Netil Studios
1-7 Westgate St.
London E8 3RL, UK
+44 20 8123 9986
www.msavisuals.com
On 3 Oct 2010, at 20:27, George Toledo wrote:
Also.... still sussing out where you are going/what you need to
do (sorry, it's taking a moment to sink in).
...but I just opened up the composition and ran it. Mass wasn't
being declared anywhere, and if you did declare it where you have
it in the javascript, it will "fart out" (excuse my highly
technical term).
This re-order allows there to be a mass value that doesn't cause
error in the javascript compiler. Apologies if my re-order
precludes something that you're trying to accomplish that's going
over my head (as in, I'm still sussing out the desires in your
original post, in relation to this qtz.)
-GT
On Sun, Oct 3, 2010 at 3:16 PM, Mehmet Akten <[email protected]> wrote:
--
Thanks george, that makes perfect sense, I'll git it a shot.
P.S. I accidentally posted this to the quartz dev list first. I
reposted on the QC list too as its more related to that.
Probably best not to continue this thread on this list.
Apologies for the double post.
MSA Visuals Ltd.
Unit 107 Netil Studios
1-7 Westgate St.
London E8 3RL, UK
+44 20 8123 9986
www.msavisuals.com
On 3 Oct 2010, at 20:11, George Toledo wrote:
Quick note: still reading through your case scenarios; the
feedback patch will work inside of the iterator if you don't
have consumer patches. The results can then be gathered in a
queue and published out, where the values can then be iterated
through again if necessary. Not saying this is necessarily
always efficient, but it's possible.
-GT
On Sun, Oct 3, 2010 at 2:58 PM, Mehmet Akten <[email protected]> wrote:
--
Hi all, a much discussed topic I'm sure...
I know QC is not designed as a 'proper' OOP programming
language etc. so a question regarding object oriented
programming re quartz composer may be irrelevant, but
nevertheless I'm trying to get my head around how best to
tackle some basic data/behaviour management approaches in QC.
Take this scenario (this isn't for anything so I don't have
specific goal, just a test case).
Case 1:
I have N initial cubes, flying around with some basic
behaviour. E.g. In this particular case, I want them to each
have a target point, they fly to their target point based on
various parameters (mass etc). When they reach their target,
they pick a new target and fly there. I'm sure I did this kinda
stuff in the past using global JS vars, but I couldn't get it
to work this time. I've attached my comp, if I have one
iteration, I see my cube, but it doesn't move. If I have more
than 1 iteration, they all appear, but then disappear after a
short while.
What I'm doing may be very hacky (JS patch in an iterator with
a global array of structures). THe feedback patch seems to try
and address this issue, but obviously doesn't work in an
iterator.
Then there's more. Imagine a few more basic scenarios.
Case 2:
1. when I click in an empty space, a new object is created and
added to the flock
2. when i click on an existing object, it is deleted
3. pressing 'e' toggles the app between 'edit' mode and 'play'
mode. in 'edit mode they all stop moving and when you click on
an existing object you get some very basic options:
a. by clicking elsewhere you can set the new target for that
object
b. pressing d deletes the object
c. numbers 1-9 defines how that particular object should be
drawn (texture, cube, sphere etc.)
d. etc.
I can imagine how to do #3 (keep track of a bool in the
root.data object). and #3c (multiplexer). #1, #2, #3a and #3b
should be straight forward too, but its the data management
that I can't get my head around.
I know if it gets too complicated it just makes sense to write
a plugin, but I just want to see exactly how far can can QC be
taken in this way regarding logic and behaviours. The scenario
I mention above doesn't seem too complicated, in fact is quite
basic and I feel you should be able to do it within a noodley
environment.
P.S. connecting the JS output to enable of a billboard worked
by the way, thanks for the tip alessandro
Cheers,
Memo.
MSA Visuals Ltd.
Unit 107 Netil Studios
1-7 Westgate St.
London E8 3RL, UK
+44 20 8123 9986
www.msavisuals.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/gtoledo3%40gmail.com
This email sent to [email protected]
George Toledo
[email protected]
www.georgetoledo.com
The information contained in this E-mail and any attachments may
be confidential.
If you have received this E-mail in error, please notify us
immediately by telephone or return E-mail.
You should not use or disclose the contents of this E-mail or
any of the attachments for any purpose or to any persons.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/gtoledo3%40gmail.com
This email sent to [email protected]
George Toledo
[email protected]
www.georgetoledo.com
The information contained in this E-mail and any attachments may
be confidential.
If you have received this E-mail in error, please notify us
immediately by telephone or return E-mail.
You should not use or disclose the contents of this E-mail or any
of the attachments for any purpose or to any persons.
<OOP test1_b.qtz>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/qc.student.au%40gmail.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/qc.student.au%40gmail.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
