Proto-Croquet Posted

Hi all,

You might be interested in viewing a video I made of ICE - the Interactive Collaboration Environment. It is available on my blog now. ICE is the proto-Croquet, a true collaboration environment I built in 1994. It was strongly influenced by Apple's OpenDoc architecture, as well as conversation I had with Alan Kay. Five years later, Alan, David Reed, Andreas Raab, Mark McCahill, Julian Lombardi and I started the Croquet project.

There are a number of cool ideas in ICE that still haven't been built. The entire ICE environment was itself a component, so it could be dropped into a scene as was demonstrated. You can view it here: <http://croqueteer.blogspot.com/>

I also posted videos of The Colony, which I guess is proto-proto Croquet. This was the game I wrote in 1987

Let me know what you think.

David

Thanks for doing this. These videos are so damn cool!

Cheers,
   - Andreas

David Smith wrote:

Very cool David ! .... thanks for sharing ! Totally amazing what you
accomplished given the hardware of the day !




======

On Tue, Jan 20, 2009 at 10:27 PM, David Smith <[hidden email]> wrote:

Genius!

I like it.

You know, I would love to have a "virtual machine" that was preloaded
with a running version of ICE (and Colony).  The video is nice, but the
artifact would be even nicer.

David Smith wrote:

I found this: <http://wiki.oldos.org/Mac/68kEmulator>. Colony was a 68K app, but I don't remember if ICE was or not. That was just when Apple made the transition to the PowerPC, and I would have likely had one of those. The machine I did the video on was a PPC. 

Hi Hans,

To grab a screenshot, look at the OpenGL methods #screenShot and #screenShot:.  You won't be able to render 360 degrees all at once, but you can render, say, 8 times, turning 45 degrees before each render (you'll have to set up your viewing frustum so that there isn't overlap).  

 

To grab a screenshot, look at the OpenGL methods #screenShot and #screenShot:.  You won't be able to render 360 degrees all at once, but you can render, say, 8 times, turning 45 degrees before each render (you'll have to set up your viewing frustum so that there isn't overlap).  

To render your objects, you can use specially-initialized TMaterials on each object.  Set the 'fullBright' of the material to 'true', and use a unique 'diffuseColor' for each object.

Alternately, you can hack the rendering code in TMaterial>>enable: so that it starts something like this (I'm starting from the version 'ar 9/9/2006 16:49')...

enable: ogl

| trans transx hilite |

"josh: comment out this line"

"hilite := ogl forceHilite."

"josh: force 'fullBright' rendering, and assign a random color... you might want to keep track of colors, I guess"

hilite := texture := nil.

fullBright := true.

diffuseColor := VectorColor r: (1000 atRandom / 1000.0) g: (1000 atRandom / 1000.0) b: (1000 atRandom / 1000.0) a: 1.0.

"josh: everything below here is the same"

hilite ifNotNil: [

 "This is not a 'hot' code path since highlighting is a special situation, so we can take enough care to create a nice appearance."

The resulting screen-shot is an instance of Form class, so there are plenty of methods to help you, for example, count the number of unique colors, and the number of pixels of each.

Have fun,

Josh

On Jan 29, 2009, at 12:31 AM, Baveco, Hans wrote:

I want to use Croquet to perform an analysis of the visibility of objects (buildings etc) in the landscape. For this I think I need to be able to do the following:

- save the results of rendering the landscape from a particular location to an image. This should preferably be a 360 degrees image, with a small height.

- the rendering to the image should be very basic. No shading etc, to ensure that we can directly identify the landscape objects on the image from their color (objects need not really to be identified, in a first step I just want to calculate the percentage of pixels of each color).

- it would be nice if the analysis of the results (e.g. pixel coverage in each image) could already be done in Croquet/Squeak, but as a first step producing external images would be ok

 

Suggestions & comments and in particular code snippets showing how to do this (e.g. OpenGL commands) are very welcome!

 

TIA

 

Hans

 

To grab a screenshot, look at the OpenGL methods #screenShot and #screenShot:.  You won't be able to render 360 degrees all at once, but you can render, say, 8 times, turning 45 degrees before each render (you'll have to set up your viewing frustum so that there isn't overlap).  

To render your objects, you can use specially-initialized TMaterials on each object.  Set the 'fullBright' of the material to 'true', and use a unique 'diffuseColor' for each object.

Alternately, you can hack the rendering code in TMaterial>>enable: so that it starts something like this (I'm starting from the version 'ar 9/9/2006 16:49')...

enable: ogl

| trans transx hilite |

"josh: comment out this line"

"hilite := ogl forceHilite."

"josh: force 'fullBright' rendering, and assign a random color... you might want to keep track of colors, I guess"

hilite := texture := nil.

fullBright := true.

diffuseColor := VectorColor r: (1000 atRandom / 1000.0) g: (1000 atRandom / 1000.0) b: (1000 atRandom / 1000.0) a: 1.0.

"josh: everything below here is the same"

hilite ifNotNil: [

 "This is not a 'hot' code path since highlighting is a special situation, so we can take enough care to create a nice appearance."

The resulting screen-shot is an instance of Form class, so there are plenty of methods to help you, for example, count the number of unique colors, and the number of pixels of each.

Have fun,

Josh

On Jan 29, 2009, at 12:31 AM, Baveco, Hans wrote:

I want to use Croquet to perform an analysis of the visibility of objects (buildings etc) in the landscape. For this I think I need to be able to do the following:

- save the results of rendering the landscape from a particular location to an image. This should preferably be a 360 degrees image, with a small height.

- the rendering to the image should be very basic. No shading etc, to ensure that we can directly identify the landscape objects on the image from their color (objects need not really to be identified, in a first step I just want to calculate the percentage of pixels of each color).

- it would be nice if the analysis of the results (e.g. pixel coverage in each image) could already be done in Croquet/Squeak, but as a first step producing external images would be ok

 

Suggestions & comments and in particular code snippets showing how to do this (e.g. OpenGL commands) are very welcome!

 

TIA

 

Hans

On 30.01.2009, at 16:46, Baveco, Hans wrote:

You do not want to rotate the avatar but the camera. See how  
#renderSnapshot: works, and how it is called in #renderWorld.

- Bert -

Thanks, I'll try it!

I understand that for obtaining a 360 degree image at certain
coordinates it is smarter to directly turn the camera.
However, in case I would like my avatar to follow a route through the
landscape, and collect only images of what the avatar sees in front of
it, wouldn't rotating the avatar be just as easy?

Hans

Okay, so I've spent some time exploring the system, in the interest of
figuring out what's where and how to use allt this.  I'm new to Squeak; my
Smalltalk experiences date back to college days and ST-80.  Since, I've been
using a variety of languages:  years each in C++, Java, C#.  But I've always
wanted to get back to the immediacy of the Smalltalk environment.  I've also
been watching and wishing for a chance to use tools like the Refactoring
Browser.

Now Squeak has the RB, and Croquet has some good stuff for shared 3D
environments, so I am thinking it's time to get back to Smalltalk.  Now for
the issues I'm having.

Squeak 3.10 has a nice release package that includes the Universes browser
and a big package of working tools, including the RB.

Croquet appears to be built on the 3.8 squeak release, with a recompiled VM.

Using the Croquet VM, I can load squeak 3.10 images no problem, and I
started there and worked forward, loading Croquet system into the 3.10 image
(with RB already in place).  I'm following the checklist in the
deployment/Homebase image in the Cobalt distribution.  This seems to work
for a while, plus or minus a few minor tweaks, but I'm failing in the
Tweak-Costume package (Tweak-Core-Object barfed on isSpecialREadBinding not
understood, so I hacked it into Object so as to move on) with an infinite
hang.  [n.b. I'm not having success using alt-. to break into the debugger;
it breaks all right but leaves the UI locked.  Is there a way to break into
a process, or am I stuck with the [reload, insert a halt into the source,
re-run] cycle?]


In the hope that all of Tweak isn't required in order to get some basic use
of Croquet, I jumped ahead to the croquet section of the checklist.  This
worked for a bit, but in Croquet-Kernel I hit an error with the
class-builder saying Mutex is already defined -- apparently it's being used
as a class-instance variable, and my image has a Mutex class.  It's a little
difficult to tell what's going on; a lot of this stuff is deep enough into
the system that when it fails the UI stops responding, so it's hard to
follow walkbacks.  


Approaching the problem from a different direction.  Starting off with a
fresh Cobalt image, and attempting to load Refactory package into it.
Squeak web pages suggest that the Universes system has the most up-to-date
and consistent releases, so I start with squeakmap to load Universes.  Then
I find that Refactory depends on AST, which in turn depends on Traits, which
logically enough seems to recompile all classes to include some extra
reflective information of some sort.  Anyhow, this seemed to be working but
failed after much compiling, with an error I've forgotten by now.


So anyway this is obviously all a big learning process for me, and I'm
enjoying that.  If any of this sounds like I could use a good swift
suggestion somewhere, I'd be very grateful to get it.  :-)


Thanks for your attention, to anybody that's read this far.


--kevin

[hidden email]

I wrote...

>Approaching the problem from a different direction.  Starting off with a
fresh Cobalt
>image, and attempting to load Refactory package into it. Squeak web pages
suggest that
>the Universes system has the most up-to-date and consistent releases, so I
start with
>squeakmap to load Universes.  Then I find that Refactory depends on AST,
which in turn
>depends on Traits, which logically enough seems to recompile all classes to
include
>some extra reflective information of some sort.  Anyhow, this seemed to be
working but
>failed after much compiling, with an error I've forgotten by now.


Sorry for airing my inexperience to the list; I've just started over, with a
fresh
Cobalt image, go to Squeakmap, load AST and it's successful.  Then loading
Refactoring
Engine, and that's successful too.  Exploring, I find that I've got
Refactoring
Browser on the open... menu, and it's all working as far as I can see,
almost like
it was easy.  :-)  I guess I was making it harder than it is, by not knowing
my way
around.

Again, sorry for the bother.


--kevin

[hidden email]

Thanks for the work and the report on it. I've been meaning to get to trying this for awhile but haven't found the time.

Cheers,
  -- John




--
John Dougan
[hidden email]