Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / 3D Theory & Graphics / The Crystal Space 3D Engine: Some questions. Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
ROME

March 15, 1999, 11:36 AM

Hi everyone,

I have been looking over the Crystal Space 3D Engine C++ source code and reading about it through the documents that are provided with it and on the site, for the past couple of weeks. I am in the design phase of my new 3D Engine ( at this point only on paper and in my mind, I code at the end) and am curious as to what experienced 3D Engine builders think about the design and style of the Crystal Space 3D Engine? Is the reason that it is comparitively slow to the Quake engine a result of the fact that it is not fully optimized, windows based, and has a whole-lot more better abilities that the Quake engine? Is its object hierarchy well done? What about its use of COM? What about its ability to be ported and expanded on with new features (how easy would it be)?

What would be great is if someone actually working on the Crystal Space 3D Engine code could reply to this, but this message is open to all. Please state how well you know 3D coding though so I can "whay" your answers. =) Thanks again. ROME.

 
Jorrit Tyberghein

March 16, 1999, 03:22 AM



ROME wrote:
>>Hi everyone,
>>
>>I have been looking over the Crystal Space 3D Engine C++ source code and reading about
>>it through the documents that are provided with it and on the site, for the past couple
>>of weeks. I am in the design phase of my new 3D Engine ( at this point only on paper and
>>in my mind, I code at the end) and am curious as to what experienced 3D Engine builders
>>think about the design and style of the Crystal Space 3D Engine? Is the reason that it
>>is comparitively slow to the Quake engine a result of the fact that it is not fully
>>optimized, windows based, and has a whole-lot more better abilities that the Quake
>>engine?

The windows do not have much to do with it. Windows will cause a little slow-down
but not that much. The engine still needs a lot of optimization and it indeed has
more features than Quake. The feature that slows down the engine most is colored
lighting which Quake does not have and Quake II only has in hardware.

>>Is its object hierarchy well done?

I'm probably biased here as I'm the main author and thus mainly responsible
for the current object hierarchy. Aside from a few things that should change
(and we will) I'm fairly satisfied about the current object hierarchy. It
seems to work very well.

>>What about its use of COM?

COM has not always been a part of Crystal Space. When we first decided to
incorporate it into CS we got some opposition and some support. The main
reason for opposition was the fact that COM belongs to Microsoft and people
did not like COM for that reason alone. COM is not perfect (far from it). But
it is a standard and it serves our purpose very well (our purpose is
dynamically loadable modules and plug-ins for Crystal Space and access to the
CS modules from other languages like Visual Basic and Java). We could have
chosen CORBA instead but we decided against that because CORBA has a little
more overhead compared to COM. CORBA is more geared towards distributed computing
while we need COM only for communication between modules which all run on
the same computer.


>>What about its
>>ability to be ported and expanded on with new features (how easy would it be)?

That depends on the features. The engine itself is flexible enough
to allow additional features. Over time many features have already been
added (and not only by me) without having to redesign the engine.

>
>>What would be great is if someone actually working on the Crystal Space 3D Engine
>>code could reply to this, but this message is open to all. Please state how well
>>you know 3D coding though so I can "whay" your answers. =) Thanks again. ROME.

I will probably give you a biased answer as I'm the main author of Crystal Space.

Greetings,



 
ROME

March 16, 1999, 03:29 PM



Jorrit Tyberghein wrote:
>>The windows do not have much to do with it. Windows will cause a little slow-down
>>but not that much. The engine still needs a lot of optimization and it indeed has
>>more features than Quake. The feature that slows down the engine most is colored
>>lighting which Quake does not have and Quake II only has in hardware.
>>
>>>>Is its object hierarchy well done?
>>
>>I'm probably biased here as I'm the main author and thus mainly responsible
>>for the current object hierarchy. Aside from a few things that should change
>>(and we will) I'm fairly satisfied about the current object hierarchy. It
>>seems to work very well.

What changes will you be making to the hierarchy??
Do you or anyone else have a tree-diagram (in .jpg format for instance), that shows the hierarchy of your 3D engine? I have made my own but it is far from complete. Why do most of your classes inheit from cBase.. Why have you implemented it if you are not using it??

>>>>What about its
>>>>ability to be ported and expanded on with new features (how easy would it be)?
>>
>>That depends on the features. The engine itself is flexible enough
>>to allow additional features. Over time many features have already been
>>added (and not only by me) without having to redesign the engine.

That is good to hear. Are their any changes that you see might be difficult to do, but hat I may avoid in my own engine? By the way, I am basing it on your oject heirarchy.. Well .. most of it. =)
>>
>>>
>>>>What would be great is if someone actually working on the Crystal Space 3D Engine
>>>>code could reply to this, but this message is open to all. Please state how well
>>>>you know 3D coding though so I can "whay" your answers. =) Thanks again. ROME.
>>
>>I will probably give you a biased answer as I'm the main author of Crystal Space.
>>
>>Greetings,
>>
Everyone is biased. =) I think my engine is the best in the world. =) See. Thanks.
>>
>>

 
Jorrit Tyberghein

March 17, 1999, 04:00 AM


>> What changes will you be making to the hierarchy??

We foresee three major changes in the near future:

- The move of the Texture management from the 3D engine to the 3D rasterizer.
I'm already busy with this and the work is near finished. The basic idea
is that the 3D engine itself will not worry about textures anymore. It will
simply register the textures with the 3D rasterizer and the 3D rasterizer
will manage them. Therefore I have to move a lot of classes.

- Maybe we are also going to try to merge the sprites and things into one
csEntity class. We have a proposal for that. This change will only affect
the sprite and thing classes of course.

- Landscape capabilities are going to add some hierarchy to the current one.
I don't think it will change the existing hierarchy much but there will be
a number of new classes.


>> Do you or anyone else have a tree-diagram (in .jpg format for instance),
>> that shows the hierarchy of your 3D engine? I have made my own but it is
>> far from complete.

You can download the automatically generated documentation (autodocs.tgz). It is HTML
and you can view a hierarchical class structure there.

>> Why do most of your classes inheit from cBase.. Why have you implemented it if
>> you are not using it??

I did not implement it. It was done by someone else. We will have to see if this class
is useful or not. I have not had time to look into that right now.

>>
>>>>That depends on the features. The engine itself is flexible enough
>>>>to allow additional features. Over time many features have already been
>>>>added (and not only by me) without having to redesign the engine.
>>
>> That is good to hear. Are their any changes that you see might be difficult to do,
>> but hat I may avoid in my own engine? By the way, I am basing it on your oject
>> heirarchy.. Well .. most of it. =)

Not that I can think of right now.

Greetings,

 
ROME

March 21, 1999, 07:13 PM



Jorrit Tyberghein wrote:
>>
>>>> What changes will you be making to the hierarchy??
>>
>>We foresee three major changes in the near future:
>>
>> - The move of the Texture management from the 3D engine to the 3D rasterizer.
>> I'm already busy with this and the work is near finished. The basic idea
>> is that the 3D engine itself will not worry about textures anymore. It will
>> simply register the textures with the 3D rasterizer and the 3D rasterizer
>> will manage them. Therefore I have to move a lot of classes.
>>

So your "texture" classes will no longer be handled in the engine but in the .dll's ??
(the rasterizer .dll's ).

>> - Maybe we are also going to try to merge the sprites and things into one
>> csEntity class. We have a proposal for that. This change will only affect
>> the sprite and thing classes of course.
>>
>> - Landscape capabilities are going to add some hierarchy to the current one.
>> I don't think it will change the existing hierarchy much but there will be
>> a number of new classes.

I assume you are refering to your upcoming "Outdoor" engine add-on. Do you know of some of the classes which will be changed?

>>
>>
>>>> Do you or anyone else have a tree-diagram (in .jpg format for instance),
>>>> that shows the hierarchy of your 3D engine? I have made my own but it is
>>>> far from complete.
>>
>>You can download the automatically generated documentation (autodocs.tgz). It is HTML
>>and you can view a hierarchical class structure there.

I will try to find that ( although I have not be able to thus far ).

>>
>>Greetings,
>>
Same to you, ROME. =)

 
Jorrit Tyberghein

March 22, 1999, 04:03 AM


>>>> - The move of the Texture management from the 3D engine to the 3D rasterizer.
>>>> I'm already busy with this and the work is near finished. The basic idea
>>>> is that the 3D engine itself will not worry about textures anymore. It will
>>>> simply register the textures with the 3D rasterizer and the 3D rasterizer
>>>> will manage them. Therefore I have to move a lot of classes.
>>>>
>>
>> So your "texture" classes will no longer be handled in the engine but in the .dll's ??
>> (the rasterizer .dll's ).

Indeed. The reason is that texture manager is very specific to the 3D rasterizer.
The hardware accelerated 3D rasterizer now have to convert the textures on the fly
because the old texture manager was optimized for the software renderer. Now every
texture manager can optimize the textures so that they are best suited for that particular
rasterizer.


>>>> - Landscape capabilities are going to add some hierarchy to the current one.
>>>> I don't think it will change the existing hierarchy much but there will be
>>>> a number of new classes.
>>
>> I assume you are refering to your upcoming "Outdoor" engine add-on. Do you know
>> of some of the classes which will be changed?

The changes will mainly go around the portal and sector classes. I'm not sure
yet what kind of changes we will need there.


>>>>You can download the automatically generated documentation (autodocs.tgz). It is HTML
>>>>and you can view a hierarchical class structure there.
>>
>> I will try to find that ( although I have not be able to thus far ).

You can download it from my page in the documents section.

Greetings,

 
This thread contains 6 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.