Updating a model is fast
29 views
Skip to first unread message
Bruce Sherwood
May 3, 2012, 1:40:20 AM5/3/12
to dis...@sfcomplex.org
I haven't completed/polished the API, but I thought you might like to
see my very first "soft" 3D object, a pulse running along a rug. I
deliberately slowed it way down, as it turns out that dynamically
changing a model in WebGL seems to be quite fast.
http://www.glowscript.org/#/user/Bruce_Sherwood/folder/Pub/program/Rug
There's a little glitch on the left edge of the pulse. Dunno yet what
that's due to. I spent much of today tracking down what turned out to
be a one-character typo (0 instead of y in a crucial but hard to spot
piece of code). Sigh. I suppose the visible glitch will take as long
to figure out.
Bruce
see my very first "soft" 3D object, a pulse running along a rug. I
deliberately slowed it way down, as it turns out that dynamically
changing a model in WebGL seems to be quite fast.
http://www.glowscript.org/#/user/Bruce_Sherwood/folder/Pub/program/Rug
There's a little glitch on the left edge of the pulse. Dunno yet what
that's due to. I spent much of today tracking down what turned out to
be a one-character typo (0 instead of y in a crucial but hard to spot
piece of code). Sigh. I suppose the visible glitch will take as long
to figure out.
Bruce
Owen Densmore
May 3, 2012, 12:10:25 PM5/3/12
to dis...@sfcomplex.org
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
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
Bruce Sherwood
May 3, 2012, 12:46:19 PM5/3/12
to dis...@sfcomplex.org
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 dis...@sfcomplex.org
> To unsubscribe from this group, send email to
> discuss+u...@sfcomplex.org
> For more options, visit this group at
> http://groups.google.com/a/sfcomplex.org/group/discuss
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 dis...@sfcomplex.org
> To unsubscribe from this group, send email to
> discuss+u...@sfcomplex.org
> For more options, visit this group at
> http://groups.google.com/a/sfcomplex.org/group/discuss
Marylee McInnes
May 3, 2012, 12:56:58 PM5/3/12
to dis...@sfcomplex.org
Very nice.
Best,
Marylee
Best,
Marylee
Bruce Sherwood
May 3, 2012, 12:58:55 PM5/3/12
to dis...@sfcomplex.org
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.
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.
Dean Gerber
May 3, 2012, 4:11:56 PM5/3/12
to dis...@sfcomplex.org
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.s...@gmail.com>
To: dis...@sfcomplex.org
Sent: Thursday, May 3, 2012 10:46 AM
Subject: Re: [sfx: Discuss] Updating a model is fast
> discuss+unsub...@sfcomplex.org
--
You received this message because you are subscribed to the Santa Fe Complex "discuss" group.
To post to this group, send email to dis...@sfcomplex.org
To unsubscribe from this group, send email to
You received this message because you are subscribed to the Santa Fe Complex "discuss" group.
To post to this group, send email to dis...@sfcomplex.org
To unsubscribe from this group, send email to
discuss+unsub...@sfcomplex.org
Bruce Sherwood
May 3, 2012, 4:17:08 PM5/3/12
to dis...@sfcomplex.org
Sounds like a good idea! I've never seen such a program editor.
Bruce
Bruce
Bruce Sherwood
May 19, 2012, 11:06:10 PM5/19/12
to dis...@sfcomplex.org
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>
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>
Reply all
Reply to author
Forward
0 new messages