Smalltalk
› Squeak
› Croquet
›
Croquet - Dev
Croquet and Blender
Locked
12
12
 
|
Hi,
I'm working for a small company that plans to use Croquet in addition to some other tools in order to create a virtual learning environment. Ideally we'd like to be able to use Blender to create the scenes and avatars for use in this environment and then import them into Croquet for the finished product. While most things I've read make it sound like this is definitely possible, the documentation for how to actually get it done is lacking. I've searched for and read many tutorials, including http://www.dmu.com/crb/crb0.html and http://www.opencroquet.org/index.php/Island_Creator/Blender_Basic_Lessons_TOC I've attempted to follow them multiple times, but there seems to be some bugs or simply a lack of clarity in how to create the islands. I've attempted using the .ase format exported from Blender, but I've run into problems trying to export anything in this way. It seems to have very tight constraints for what sorts of textures can be used and I've yet to successfully export a scene created in Blender using this format. However, I've seen mention of using the .obj format instead, which I have successfully exported scenes in. That seems like it would be easier, but I haven't seen any mention of the best way to actually use this format in Croquet. Ideally I'd like to be able to create a complete scene in Blender using the texture and material tools included in that program and then simply export it as is into Croquet to create a new island. I don't know if this is asking too much, but I was wondering if you could clarify this for me, and possibly point me to a tutorial that could either explain this or simply set out the constraints I would have to work under in order to export a scene from Blender into Croquet. Thanks a bunch, Dan Waters |
|
|
Hi Dan, Americo started with the .ase import with the www.dmu.com tutorials, eg the Magic Ninja series. The .obj scene import is the current method in the Cobalt manual. Just take a note that if you import and entire scene made in Blender it all has to be one mesh, so join all your separate object meshes to, say the ground mesh. Also you can only have one texture apllied to the mesh, so if you have a bunch of texture's mapped you'll have to bake them. Also, beware that there were some issue's using the skeletal animation package with the old Cobalt browser classes, I'm not sure if this is fixed in the new release. The skeletal animation package works with the San Minimun Island provided in the manual if you want to do some tests. wfpi On 6/18/08, dlw1@williams.edu <[hidden email]> wrote: Hi, |
|
|
In reply to this post by dlw1
Dan,
I've been working with Croquet for over two years in order to build a virtual learning environment and I ran in to many of the same problems you are struggling with. You will find that the Croquet community is very slow and the documentation is nearly unusable. I attempted to provide some better documentation at my blog, which you can find here: http://xaverse.blogspot.com Hope this helps, Matt On Wed, Jun 18, 2008 at 12:04 PM, <[hidden email]> wrote: Hi, |
|
|
Dan, don't be discouraged by this oppinion. I've been on Croquet for just over six months now. When I first started I had trouble with OpenAL(my own stupidity) and, I believe David Frought, responded in a day. When I had trouble with the skeletal animation package Peter Moore was back and forth with me to help. I had trouble with the sky box, and Julian Lombardi was back at me within an afternoon. Americo, English is his second language, has been gracious enough to write excellent starter manuals(WIP!) for Croquet/Cobalt and Squeak proper. As an international community we should be grateful to community members who surpass a language barrier to provide documentation in English(could be in Portuguese). And, not for nothing, (while I'm not in these guys league) I believe I was back to you in say....10-15 minutes. Remember though both they Wizards and Users are typically employed full time and are involved in the project because they see it as important. Nuff said! Dev list really isn't the place for this wfpi On 6/19/08, Matthew Schmidt <[hidden email]> wrote: Dan, |
|
|
In reply to this post by Matthew Schmidt-2
At the link of the Mattew's post (his blog) there are a recomendation against
Croquet and saying that SUN's Wonderland is the "way to go". Wonderland is a nice project, but it's important to say that shared applications only work for the Linux and Solaris versions. So: it's not a multiplataform system like Croquet. Like you can read at: https://lg3d-wonderland.dev.java.net/#devdoc "Application sharing is supported only for X11 applications and hence available on Linux and Solaris platforms only. Shared X11 applications must be launched from a Linux or Solaris client but can be viewed and controlled from any other client (including Windows and Mac)" |
|
|
Windows is on the descent path. Cutting edge applications should all be
moving to a more open platform, and Windows is not now nor will it ever be an open and competitive platform for cutting edge applications. I don't find Croquet friendly on X11 and linux because it requires additional libraries that are not cleanly specified. Also the interface is not good to X11 at this time. But because I have been of limited success to move it to Fedora 8, and with the move to Fedora 9 looming on the horizon, I am unsure that I should spend more time on it. At the same time, I have had to go back to work from retirement. This impacts my available time, which tied to a difficult X interface means less profitable time, more energy spent on debug, and less on productive work, so I am sort of "out of sorts" with Croquet in the mean time. On the other hand, the platform does have promise, but Windows being supported for linking of applications which can run code on my machine, with windows having more security holes than swiss cheese makes this less than attractive. I don't know the answers to these issues, and I wish I did. I personally liked the interface to Croquet once I had it running on Fedora 7. But issues with the latest openGL seem to be the issue, and I wonder if Croquet is calling outdated functions? Regards, Les H On Fri, 2008-06-20 at 08:16 -0400, Americo Damasceno wrote: > At the link of the Mattew's post (his blog) there are a recomendation against > Croquet and saying that SUN's Wonderland is the "way to go". > > Wonderland is a nice project, but it's important to say that shared > applications only work for the Linux and Solaris versions. So: it's not a > multiplataform system like Croquet. Like you can read at: > > https://lg3d-wonderland.dev.java.net/#devdoc > > "Application sharing is supported only for X11 applications and hence available > on Linux and Solaris platforms only. Shared X11 applications must be launched > from a Linux or Solaris client but can be viewed and controlled from any other > client (including Windows and Mac)" |
|
|
Good Lord. Must the Windows-is-awful crowd, the Mac-is-perfect crowd,
and the Linux-hackers-are-indisputably-gods crowds always drive any discussion into the weeds? All of these OS's royally *suck* for many reasons. But so what? That's why Squeak is self-contained, and should be moreso. Someone should make a Squeak that runs directly on X86 laptops, so then people can run it in VMWare, Parallels or KVM or VirtualBox as they wish. Les wrote: > Windows is on the descent path. Cutting edge applications should all be > moving to a more open platform, and Windows is not now nor will it ever > be an open and competitive platform for cutting edge applications. > > I don't find Croquet friendly on X11 and linux because it requires > additional libraries that are not cleanly specified. Also the interface > is not good to X11 at this time. But because I have been of limited > success to move it to Fedora 8, and with the move to Fedora 9 looming on > the horizon, I am unsure that I should spend more time on it. > > At the same time, I have had to go back to work from retirement. This > impacts my available time, which tied to a difficult X interface means > less profitable time, more energy spent on debug, and less on productive > work, so I am sort of "out of sorts" with Croquet in the mean time. On > the other hand, the platform does have promise, but Windows being > supported for linking of applications which can run code on my machine, > with windows having more security holes than swiss cheese makes this > less than attractive. I don't know the answers to these issues, and I > wish I did. I personally liked the interface to Croquet once I had it > running on Fedora 7. But issues with the latest openGL seem to be the > issue, and I wonder if Croquet is calling outdated functions? > > Regards, > Les H > On Fri, 2008-06-20 at 08:16 -0400, Americo Damasceno wrote: > >> At the link of the Mattew's post (his blog) there are a recomendation against >> Croquet and saying that SUN's Wonderland is the "way to go". >> >> Wonderland is a nice project, but it's important to say that shared >> applications only work for the Linux and Solaris versions. So: it's not a >> multiplataform system like Croquet. Like you can read at: >> >> https://lg3d-wonderland.dev.java.net/#devdoc >> >> "Application sharing is supported only for X11 applications and hence available >> on Linux and Solaris platforms only. Shared X11 applications must be launched >> from a Linux or Solaris client but can be viewed and controlled from any other >> client (including Windows and Mac)" >> > > > |
re: Squeak with no host operating system (was "Croquet and Blender")
|
|
> Someone should make a Squeak that runs directly on X86 laptops, so > then people can run it in VMWare, Parallels or KVM or VirtualBox as > they wish. The SqueakNOS project is booting that way, but as usual the main challenge is writing a critical mass of device driver support. -C |
Re: re: Squeak with no host operating system (was "Croquet and Blender")
|
|
Understand. Of course to run on VMWare, KVM, and Parallels, one need
only support one variant of each device type (chipset, keyboard, display, mouse, network, disk). That simplifies life considerably! In other words, it's a MUCH simpler problem if you don't need to port to each mfr's world. Craig Latta wrote: > > > Someone should make a Squeak that runs directly on X86 laptops, so > > then people can run it in VMWare, Parallels or KVM or VirtualBox as > > they wish. > > The SqueakNOS project is booting that way, but as usual the main > challenge is writing a critical mass of device driver support. > > > -C > > > |
|
|
In reply to this post by Les Howell
|
|
|
In reply to this post by David P. Reed
On Fri, Jun 20, 2008 at 12:39:50PM -0400, David P. Reed wrote:
> All of these OS's royally *suck* for many reasons. But so what? That's > why Squeak is self-contained, and should be moreso. Someone should > make a Squeak that runs directly on X86 laptops, so then people can run And all x86 suck, for many reasons. So we can't stay hardware-agnostic, especially as right now mainstream hardware is branching out into massive parallelism, and IIRC Smalltalk doesn't implicitly support such. > it in VMWare, Parallels or KVM or VirtualBox as they wish. -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE |
|
|
Eugen Leitl wrote:
> hardware is branching out into > massive parallelism, and IIRC Smalltalk doesn't implicitly support > such. Smalltalk on the GPU or Cell ? |
|
|
In reply to this post by Eugen Leitl
On Sat, 2008-06-21 at 12:32 +0200, Eugen Leitl wrote: > On Fri, Jun 20, 2008 at 12:39:50PM -0400, David P. Reed wrote: > > > All of these OS's royally *suck* for many reasons. But so what? That's > > why Squeak is self-contained, and should be moreso. Someone should > > make a Squeak that runs directly on X86 laptops, so then people can run > > And all x86 suck, for many reasons. So we can't stay hardware-agnostic, > especially as right now mainstream hardware is branching out into > massive parallelism, and IIRC Smalltalk doesn't implicitly support > such. capabilities. But with the time messaging model, parallelism also carries additional overhead. Parallel processes must of course be thread safe if real time scheduling occurs, and if processors are selected based upon availability or load the execution time is not guaranteed. This means the process can become somewhat chaotic unless the programmer or the program constrains the sequence of execution for those things that are sequence dependent, and since not all things are sequence dependent, some means of prioritizing and dealing with the non sequence dependent pieces would also be nice to assist with scheduling that is perception corrected. In otherwords those things that perception says should happen in a linear time continuum would be correctly timed and localized. > > > it in VMWare, Parallels or KVM or VirtualBox as they wish. > A real time process that is virtualised (sp?) has several advantages, but is also somewhat crippled because it now has a scheduler running in a scheduler (depending on the means of virtualization) However the advantage of virtualizing the disk access might mitigate some of the security issues. I am no expert on this. I have written a virtual machine a long time ago, but at that time security was not one of the issues I was addressing. Regards, Les H |
|
|
In reply to this post by hendikon
On Sat, 2008-06-21 at 11:59 +0100, Matthew Chadwick wrote: > Eugen Leitl wrote: > > hardware is branching out into > > massive parallelism, and IIRC Smalltalk doesn't implicitly support > > such. > > Smalltalk on the GPU or Cell ? By GPU do you mean the Graphics Processing Unit, or Global Processing Unit. If the first, that is already part of the processing using OpenGL, and is intrinsic. If you mean Global Processing Unit, then that would add some overhead via the eithernet scheduling and messaging, when you already have it pretty loaded if the Island has several visitors (think of how Second Life has shut down when overloaded.) The Cell is also already in some systems as a graphics processing unit (although often a limited design) However it is generically hardware intensive (bandwidth issues), and close coupled in application. I haven't experimented with Cell software, but would sure love to someday. The problem with Cell is that programming it is pretty challenging according to the sources I just consulted. Can SmallTalk specifically Squeak take advantage of these concepts is one question, but more importantly is it possible to write Squeak code on one type of system (standard X86 or PowerPC or whatever Apple is running these days) and move that resultant code to a parallel processing system such as GPU or Cell, and gain the advantage that gigaflop capability adds? Regards, Les H |
|
|
In reply to this post by Eugen Leitl
Am 21.06.2008 um 12:32 schrieb Eugen Leitl: > On Fri, Jun 20, 2008 at 12:39:50PM -0400, David P. Reed wrote: > >> All of these OS's royally *suck* for many reasons. But so what? >> That's >> why Squeak is self-contained, and should be moreso. Someone should >> make a Squeak that runs directly on X86 laptops, so then people >> can run > > And all x86 suck, for many reasons. So we can't stay hardware- > agnostic, > especially as right now mainstream hardware is branching out into > massive parallelism, and IIRC Smalltalk doesn't implicitly support > such. You don't need parallelism for in-island computation. IMHO it's a major drawback that Squeak uses the same VM for in-island and off-island computation, otherwise it would be easy to use one CPU for each island and as many CPU/GPU's you have for off-island rendering. /Andreas |
|
|
In reply to this post by Les Howell
Les wrote:
> and move that resultant code to a parallel > processing system such as GPU or Cell, and gain the advantage that > gigaflop capability adds? Yes! Having done a little GPGPU work recently, I wanted to be able to declare a class Parallel, perhaps, and run millions of instances on the GPU directly. For certain kinds of problem it would be great. Were anyone ever to port Squeak to the PS3 then it would be nice to have a way to run objects on the SPUs. |
|
|
Linux has been ported to the PS2, and OpenGL permits Croquet/Cobalt to
run on Linux. I think you are about 1/2 way there. Regards, Les H On Sat, 2008-06-21 at 20:09 +0100, Matthew Chadwick wrote: > Les wrote: > > and move that resultant code to a parallel > > processing system such as GPU or Cell, and gain the advantage that > > gigaflop capability adds? > > Yes! Having done a little GPGPU work recently, I wanted to be able to > declare a class Parallel, perhaps, and run millions of instances on the > GPU directly. For certain kinds of problem it would be great. Were > anyone ever to port Squeak to the PS3 then it would be nice to have a > way to run objects on the SPUs. |
|
|
In reply to this post by Andreas Vox-2
Am 21.06.2008 um 20:22 schrieb Andreas Vox: > You don't need parallelism for in-island computation. IMHO it's a > major drawback > that Squeak uses the same VM for in-island and off-island > computation, otherwise > it would be easy to use one CPU for each island and as many CPU/ > GPU's you have for > off-island rendering. That is exactly what the Squeak "Hydra" VM does. - Bert - |
|
|
Bert Freudenberg wrote:
> Am 21.06.2008 um 20:22 schrieb Andreas Vox: >> You don't need parallelism for in-island computation. IMHO it's a >> major drawback >> that Squeak uses the same VM for in-island and off-island computation, >> otherwise >> it would be easy to use one CPU for each island and as many CPU/GPU's >> you have for >> off-island rendering. > > That is exactly what the Squeak "Hydra" VM does. Small correction: It should be referred to as the Croquet Hydra VM for precisely the reasons you're all laying out ;-) If not for Croquet, Hydra wouldn't exist. Cheers, - Andreas |
|
|
In reply to this post by Americo Damasceno
At the link of the Mattew's post (his blog) there are a recomendation against For the record, there is no recommendation at my blog against Croquet, nor is there any reference to Sun's Wonderland being the "way to go". It is, however, true that Wonderland is not a multiplatform system like Croquet. It is a multiplatform system that is in some ways similar to Croquet, but also different in some ways. Ultimately, they are two very different systems and each one has its pros and cons. It was not my intention to start a Croquet vs. Wonderland debate. A diverse metaverse ecosystem is important and lessons can be learned from all current metaverse platform efforts because, as with operating systems, processors, etc., there are some things that some platforms do very well, and some things that they do not do well at all. Cheers, -Matt |
«
Return to Croquet - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |