Congrats! I'm surprised how little CPU it takes on my MBAir .. WebGL
rocks from that standpoint.

I'm interested in the performance because I'm toying with the idea of
a subset of NetLogoJS, patches, agents, graphs and so on and the
performance would be important.

My temptation is to use a 2D API on the canvas object, mainly because
WebGL is so difficult to debug.

I'm considering CoffeeScript rather than JS too, mainly because it has
such good enumeration and comprehensions .. it might actually obviate
the need for the "with" primitive for patch/agent sets, and so on.

   -- Owen

On Wed, May 2, 2012 at 11:40 PM, Bruce Sherwood

I found a mistake in my calculations of the normals, now fixed, so if
you look again at my rug demo the display is significantly improved
(and the glitch on the left of the pulse is gone).

GlowScript creates a set of meshes (arrow, box, cone, curve, cylinder,
pyramid, sphere) which reside in GPU memory from which instances of
these objects get their geometry data, individualized by instance
attributes pos, color, opacity, size, axis, and up. The new thing is
that users can create their own meshes, and instances of these meshes
(and note that if you change a mesh, all the instances change
instantly). There was a question whether dynamic changes to a mesh
would have serious performance problems, since GPU memory has to be
updated. My rug example shows that performance is fine -- not a
problem. Evidently sending the update to the card isn't very
expensive.

This is in marked contrast to the slowness of readPixels to get
information from GPU -> CPU. Apparently this slowness is mainly due to
the necessity of syncing the GPUs with the CPU, not with the data
transfer itself. For example, I use false-color mouse picking where I
read just one pixel, the one under the mouse. This typically takes an
enormous tenth of a second!

Owen, you had asked whether I had run into any problems with
CoffeeScript. The answer is yes, but it has more to do with the editor
used in GlowScript than with the CoffeeScript language. We use the ACE
editor, which includes a helper thread that continually examines your
program while you're editing and places discreet little markers beside
statements that might have problems (e.g. missing parenthesis), all of
course keyed to JavaScript. Certain kinds of errors stop the helper;
it can't continue. The result is that in ACE the helper is always
stopped when editing CoffeeScript. I don't think this is trivial to
fix in ACE, and I need to look around to see if there's a good
CoffeeScript editor we could use.

Also, there is significant preprocessing of a GlowScript file from
JavaScript (created directly or converted from CoffeeScript) to
JavaScript, to permit infinite loops and vector addition and
subtraction. Scherer put in comment lines containing the original line
numbers to give in case of error, and I need to revisit that machinery
because now the "original" JavaScript might be converted from
CoffeeScript and therefore the reported line number need not be very
close to what you wrote.

Finally, there is a real CoffeeScript problem, one I'm familiar with
from Python. Whitespace is great, but sometimes indentation errors are
hard to spot and fix, especially if you have a somewhat longish
indentation. The problem is similar to the problem in non-whitespace
languages where you may have trouble seeing which set of braces
surrounds a long block of code. Even though most editors nowadays help
you match up braces, if the matching brace is outside the page being
viewed it can still be annoying.

Bruce

Very nice.

Best,
Marylee

I would be interested in collaborating on improving the graphics in
NetLogo. Ruth and I are very impressed with NetLogo and see it as a
better choice than VPython/GlowScript for many kinds of modeling
activities. I'm also impressed by NetLogo's excellent coordination of
code and direct manipulation (of such things as sliders and buttons),
something that has bee done poorly in many previous attempts at that
sort of thing.

It seems possible that we could extract the basic graphics machinery
from GlowScript and use it, already largely debugged, in NetLogo.
Frankly, I think it would be a serious mistake in 2012 to settle for
2D.

Bruce

Very interesting, these missives on coffee, etc.  Question: why does 'white space" have to be white?  Could not colored white space make the perception of  indentation and bracket matching easier, now that color monitors are ubiquitous?  Just asking  ...Dean Gerber

________________________________
 From: Bruce Sherwood <bruce.sherw...@gmail.com>
To: disc...@sfcomplex.org
Sent: Thursday, May 3, 2012 10:46 AM
Subject: Re: [sfx: Discuss] Updating a model is fast

I found a mistake in my calculations of the normals, now fixed, so if
you look again at my rug demo the display is significantly improved
(and the glitch on the left of the pulse is gone).

GlowScript creates a set of meshes (arrow, box, cone, curve, cylinder,
pyramid, sphere) which reside in GPU memory from which instances of
these objects get their geometry data, individualized by instance
attributes pos, color, opacity, size, axis, and up. The new thing is
that users can create their own meshes, and instances of these meshes
(and note that if you change a mesh, all the instances change
instantly). There was a question whether dynamic changes to a mesh
would have serious performance problems, since GPU memory has to be
updated. My rug example shows that performance is fine -- not a
problem. Evidently sending the update to the card isn't very
expensive.

This is in marked contrast to the slowness of readPixels to get
information from GPU -> CPU. Apparently this slowness is mainly due to
the necessity of syncing the GPUs with the CPU, not with the data
transfer itself. For example, I use false-color mouse picking where I
read just one pixel, the one under the mouse. This typically takes an
enormous tenth of a second!

Owen, you had asked whether I had run into any problems with
CoffeeScript. The answer is yes, but it has more to do with the editor
used in GlowScript than with the CoffeeScript language. We use the ACE
editor, which includes a helper thread that continually examines your
program while you're editing and places discreet little markers beside
statements that might have problems (e.g. missing parenthesis), all of
course keyed to JavaScript. Certain kinds of errors stop the helper;
it can't continue. The result is that in ACE the helper is always
stopped when editing CoffeeScript. I don't think this is trivial to
fix in ACE, and I need to look around to see if there's a good
CoffeeScript editor we could use.

Also, there is significant preprocessing of a GlowScript file from
JavaScript (created directly or converted from CoffeeScript) to
JavaScript, to permit infinite loops and vector addition and
subtraction. Scherer put in comment lines containing the original line
numbers to give in case of error, and I need to revisit that machinery
because now the "original" JavaScript might be converted from
CoffeeScript and therefore the reported line number need not be very
close to what you wrote.

Finally, there is a real CoffeeScript problem, one I'm familiar with
from Python. Whitespace is great, but sometimes indentation errors are
hard to spot and fix, especially if you have a somewhat longish
indentation. The problem is similar to the problem in non-whitespace
languages where you may have trouble seeing which set of braces
surrounds a long block of code. Even though most editors nowadays help
you match up braces, if the matching brace is outside the page being
viewed it can still be annoying.

Bruce

--
You received this message because you are subscribed to the Santa Fe Complex "discuss" group.
To post to this group, send email to disc...@sfcomplex.org
To unsubscribe from this group, send email to
discuss+unsubscr...@sfcomplex.org
For more options, visit this group at
http://groups.google.com/a/sfcomplex.org/group/discuss

Sounds like a good idea! I've never seen such a program editor.

Bruce

David Scherer posted to the GlowScript forum a note explaining how one
can use the GlowScript libraries outside the glowscript.org
environment today; no further development is needed, to my surprise. I
append below what he says (he refers to an earlier note I had written
in response to a question from an original poster about doing this).
If you post his html code on a server you'll find that you can get a
rotating cube on your screen. The rate statement means "clamp the
iteration rate to 100 per second", which determines the animation
speed.

Bruce

I want to clarify that what the original poster wanted is possible,
just not very user friendly.

By far the *easiest* way to embed a glowscript program in your web
page is to edit it at glowscript.org and then use the "Share" feature
to get HTML source.  This is easiest because the glowscript.org
environment applies a number of transformations from "glowscript
source" to pure javascript (to add operator overloading and
asynchronous features, as Bruce mentions).

But a knowledgable javascript programmer should certainly be able to
make use of the 'glow' javascript library directly, and this could
make sense for some purposes.  They will just have to write in pure
javascript, without operator overloading and with callbacks instead of
the wait keyword.  And they would have a tiny bit of initialization
boilerplate to write, like creating a canvas.

Here is a minimal working example HTML file:

<html>
<body>
<div id="glowscript" class="glowscript">
<script type="text/javascript"
src="http://www.glowscript.org/lib/jquery/jquery-1.6.2.min.js"></script>
<script type="text/javascript"
src="http://www.glowscript.org/package/glow.0.7.min.js"></script>
<script type="text/javascript">
window.__context = { glowscript_container: $("#glowscript").removeAttr("id") }

var scene = canvas( { } )
b = box()
function update() {
  b.rotate( { angle:.01, axis:vec(0,1,0) } )
  rate(100, update)

update()

</script>
</div>
</body>
</html>

On Thu, May 3, 2012 at 10:58 AM, Bruce Sherwood