Why rolling your own 3D engine?

> Hi
>
> I'm a discrete observer of your project for quite some time, and as
> your v1.0 release comes out, i'd like to ask a few questions.
>
> I'm pretty curious about this. Croquet seems really very innovative in
> terms of:
> - network design: decentralized, p2p-like architecture
> - computing design, programming languages used
> - UI / Human to human interface
> - portability
> - integrability/interoperability with regular desktop apps (such as
> firefox in your collaborative app) ! You're certainly the only ones to
> do this
> ...
>
> Still, i don't understand why keeping the hasstle of maintaining your
> own 3D engine. There are great open source crossplatform 3D
> apps/engines/apis out there (http://en.wikipedia.org/wiki/OGRE_3D,
> http://irrlicht.sourceforge.net/features.html,
> http://en.wikipedia.org/wiki/JMonkey_Engine,
> http://www.openscenegraph.com/index.php ...), which could let you
> concentrate on the networking side.
>
> Don't get it wrong, but the fact is that your engine will *always* be
> outdated, in the technological sense. I know it's not your purpose at
> all, but maybe you could find something that fits opencroquet on the
> philosophical and technological sides (the Ancient Spaces project
> approach... Couldn't find any binary though)...
>
> If you want a community to form, don't you need:
>
> - an easy-to-use/all-in-one integrated modeler? Such as sketchup or
> blender  (well, ok, not easy to use :p); blender has a full-feaured
> embedded game engine for instance, which could take care of all
> 3D/cinematic/physics engines. Your work isn't about eye-candy or
> animation ... So why not handling it to another project? Maybe
> adopting a 3D-engine-independant design (but, this would certainly
> break some interoperability)
>
> - the modelization wall prevents lots of users to get into 3D stuff.
> But, as recent efforts showed, modelization of objects/people from
> photos/videos is becoming a reality (3D scanners / 3D printers /
> http://en.wikipedia.org/wiki/Sketch_based_modeling ,
> http://en.wikipedia.org/wiki/Image-based_modeling_and_rendering )
>
> - a big 3D objects library to take objects from (Google 3D
> warehouse...), there are export/convert scripts already:
> * Blender <- Sketchup:
> http://jmsoler.free.fr/didacticiel/blender/tutor/py_import_kml-kmz_en.htm
> * Sketchup -> Ogre
> http://www.ogre3d.org/wiki/index.php/Sketchup_Exporter
>
> - continue on integrating regular desktop apps, if not 3D apps (google
> earth/world wind)
>
> - as for NAT issues, somebody recently envisioned OpenID servers as
> both Identity servers and rendez vous points, and this is surely an
> interesting idea; see:
> http://blog.nona.net/2007/03/20/yet-another-openid-application-this-time-p2p-sip/ 
>
> , http://www.mocaedu.com/mt/archives/000293.html . This may come out
> as an interesting alternative to rendez-vous, because of it's
> reusability and openness
>
> I understand that croquet is mainly a research project, and more
> backend-oriented, but sometimes research projects gain unpredicted
> popularity and dynamism boost when getting some key elements. Plus,
> research projects don't always reach 1.0 release state ... Especially
> on the 3D-web side (so many dead projects :-\). Please excuse me for
> saying things you probably already heard about, there's absolutely no
> offense intended.
>
> I'm glad to see a real big public release, i was keeping an eye on
> croquet since a few years, and didn't see it move a lot (on the public
> side). I'm sure your project has a definite future !
>
> Could you maybe develop your expectation towards croquet for the next
> 2-5 years? I'd be glad to know what you're wishing your project to
> become.
>
> Especially on:
> - the semantics side (http://en.wikipedia.org/wiki/Metaweb)
> - the web2.0 mashup integration side (http://programmableweb.com/),
> for seamless web integration
> - the messaging side
> - the "bot" side (applications in NPCs / objects)
> - distributed 3D rendering
> - any point you'd imagine
>
> Cheers, and please keep up the good work.
>
> Florent Thiery
>
> PS: i NEVER should have read this damn snowcrash novel.... >.<

>
>>> Perhaps you should look under the covers of the
>>> engine before declaring it to be *always* outdated.
>>
>> Yes, you are right. Let me apologize for the rough speaking. Still, i
>> was thinking of "modern" built-in capabilities, such as shaders, bump
>> mapping, etc...
>
> These will hopefully be available in the relatively near future.  
> While at the University of Wisconsin, I developed a framework for  
> using CgFX materials in Croquet.  While working for us as a student-
> intern, Kael Greco used this framework to write several very nice  
> materials, including bump-mapping and toon-shading with silhouette  
> edges.
>
> This was done in the previous "Jasmine" version of Croquet, which  
> has significant architectural differences from the current  
> "Hedgehog" version, so there is a small amount of redesign that  
> needs to be done.  It is just a matter of finding the time to  
> integrate this into the current release.
>
> Cheers,
> Josh

>> Perhaps you should look under the covers of the
>> engine before declaring it to be *always* outdated.
>
> Yes, you are right. Let me apologize for the rough speaking. Still, i
> was thinking of "modern" built-in capabilities, such as shaders, bump
> mapping, etc...
>
>> Since every object can define its own rendering capability
>
> Does it mean that an object itself can contain the "more sophistical"
> rendering procedures, i.e. directly drive the rendering method ? Such
> as (let me take the same example) bump mapping?

>> Most 3D engines are extremely restrictive in the nature of the user
>> interactions.
>
> Ok. So APIs would be the right term then (ex: physics model APIs like
> newton), for everything not involving user interaction directly (if
> you stick to pure eye candy or cinematic capabilities); my question
> was miswritten.
>
>> Modifying an existing engine to do this would be no small task.
>
> That's for sure !
>
>> Regards,
>>
>> David
>
> Thanks for your answears !
>
> Florent

> > Perhaps you should look under the covers of the
> > engine before declaring it to be *always* outdated.
>
> Yes, you are right. Let me apologize for the rough speaking. Still, i
> was thinking of "modern" built-in capabilities, such as shaders, bump
> mapping, etc...
>
> > Since every object can define its own rendering capability
>
> Does it mean that an object itself can contain the "more sophistical"
> rendering procedures, i.e. directly drive the rendering method ? Such
> as (let me take the same example) bump mapping?
>
> > that can be done inside of OpenGL can be done in Croquet.
>
> Of course, but everything that can be done using a C compiler can be
> done using assembly code :) (i hope i wrote it right, please excuse my
> non-native english)
>
> > Most 3D engines are extremely restrictive in the nature of the user
> > interactions.
>
> Ok. So APIs would be the right term then (ex: physics model APIs like
> newton), for everything not involving user interaction directly (if
> you stick to pure eye candy or cinematic capabilities); my question
> was miswritten.
>
> > Modifying an existing engine to do this would be no small task.
>
> That's for sure !
>
> > Regards,
> >
> > David
>
> Thanks for your answears !
>
> Florent

> There already exists importers for .obj files including one that I
> recently posted to this list. I will work to get mine into one of the
> code repositories for you to use if you'd like.
>
> Peter Moore
> University Technology Development Center
> University of Minnesota
> [hidden email] <mailto:[hidden email]>
>
> On Mar 29, 2007, at 12:53 PM, Jeffrey McGrew wrote:
>
>>
>> On Mar 29, 2007, at 10:31 AM, David A Smith wrote:
>>> Support for existing file standards is very high on our list -
>>> though I can't say when this will be released. Let's just say that
>>> we really like Sketchup and Blender. Unfortunately, neither of these
>>> applications was designed to be collaborative in the way Croquet is.
>>> I am interested in a truly collaborative design tool and have done a
>>> number of prototypes toward this called Wicket. It would be quite
>>> different from other systems that are out there. I have built this
>>> kind of thing before - I created Virtus Walkthrough in 1990.
>>
>> While I very much look forward to helping out with Wicket in any way
>> that I can, I sadly fall more onto the artist side than the
>> programming side. And even more sadly, the only 3D authoring tool
>> that can export the required .ase files Croquet makes use of is 3D
>> Studio Max. Blender had an export script, but it's fallen behind and
>> now doesn't work.
>>
>> If you want to get better models for Croquet, one stopgap would be to
>> find someone with some Python chops to update the .ase exporter for
>> Blender. This would allow people to develop models for Croquet within
>> Blender instead of an expensive application that only runs on one OS. ;-)
>>
>> Jeffrey McGrew
>> www.becausewecan.org
>>
>> p.s. I also very, very much want to help make Wicket viable for CNC
>> production and 3D printing techniques...
>>
>

> Hi, Florent,
>         I am new to Croquet, but have some experience in software DSP and
> graphics techniques.  Going from C to assembly is not difficult.  But
> the gains from a high level language for rendering are considerable, in
> coding time, debug time, and memory management.  The hit in execution
> time can be managed by handoptimizing only the required areas of intense
> time, which can be discovered by simple time histograms of code
> execution time.  These are trivial techniques.  However, producing
> re-entrant, real time, multi-tasking, multi-processing code in assembly
> is beyond most mortals, and taxes even the gurus, but this is the
> requirement for a collaborative engine such as Croquet.
>
>         I have not yet delved deeply into the code architecture for Croquet,
> but plan to do so very soon.  However, from the analysis I have done so
> far, the system is quite uniquely positioned in the userspace for
> collaborative design.  What you are thinking it probably true if I
> understand you correctly, however, managing the task in, for example,
> assembly language would be nearly impossible.  Add the requirements for
> patches, updates, reassignment of subsystem calls, and so forth, the
> task becomes more than most would even undertake, and no one that I know
> (and I know a large number of programmers) would be able to complete in
> any reasonable time.
>
>         And while object oriented code is far from perfect, its use in
> developing complex projects has proven effective.  However it comes with
> certain overhead that must be managed to be successful.  Thus some forms
> of code are pushed in directions of assembly, some are pushed in
> straight procedural/memory map models, some in object structure models,
> some in object oriented models, and some in list models.  A few even
> adapt only fully in self expanding code models (such as Forth).  The
> task for the developer is to chose the correct tool and apply it well.
> And sometimes the gains are not sufficient for a functioning programmer
> to adapt a new language or model, especially if time is a constraint.
> Working, reasonably efficient code is far better than non working code.
>
>         And while this may not address your specific question, I hope it casts
> some light into the dark corners of development issues.
>
>         I am sure that I don't know all of the issues, and others may say I am
> not correct, but this is the burden of my experience.