As the gl3ds became too large i decided to split it up. But i am running into some problems with that.

The idea is that i have a generic model class named TModel and for Loading i have an inherited class T3dsModel and an TMsaModel and even more file formats are possible this way. For rendering i have a TglModel. A TdxModel could come along too.
In TModel Render and LoadFromFile are virual and abstract.

useage is like this:

mesh1:=TModel.Create(nil);
TMsaModel(mesh1).LoadFromFile('models\hog2.txt');

and rendering like:
TglModel(mesh1).Render;

Things are working just fine, althoug i get a lot of warnings from turbo delphi like:
[Pascal Warning] Model3ds.pas(40): W1010 Method 'LoadFromFile' hides virtual method of base type 'TModel'
and
[Pascal Warning] OpenGL15_MainForm.pas(197): W1020 Constructing instance of 'TModel' containing abstract method 'TModel.LoadFromFile'
and more like those 2 warnings.

How do i fix these? I do like the concept of having a TModel class and use that with typecasting for loading and rendering. Thanks for your ideas in advance.

You can download the complete source here: http://www.noeska.com/downloads/FrameWork3d.zip

_________________
http://3das.noeska.com - create adventure games without programming

I split up some more:

TBaseModel
-TModel
-TRenderModel
--TglModel
-TLoadSaveModel
--TMsaModel
--T3dsModel

The abstract funtions are in TRenderModel and TLoadSaveModel
In TglModel/TMsaModel/T3dsModel i use reintroduce;

Now i can still use:
mesh1:=TModel.Create(nil);
TMsaModel(mesh1).LoadFromFile('models\hog2.txt');

and rendering like:
TglModel(mesh1).Render;

Without a lot of warnings....

Complet Source is for downloat at: http://www.noeska.com/downloads/FrameWork3d-2.zip

Now i need to find out if i can prevent direct usage of TBaseModel but keep shared code there.

_________________
http://3das.noeska.com - create adventure games without programming

You should use override in the derived classes instead of reintroduce. Then the correct method is called automatically and no typecasting is needed.

I try that,

But i now can also do:
mesh1:=TModel.Create(nil); //Notice that this is just TModel
T3dsModel(mesh1).LoadFromFile('models\tulip.3ds'); //T3dsModel
TMsaModel(mesh1).SaveToFile('tulip.txt'); //TMsaModel
TglModel(mesh1).Render; //TglModel

See that i do not start with a specific model type. So i have to use typecasting as it still would not be able to gues the wanted fileformat and/or way for rendering.

As always ideas for improving are welcome.

_________________
http://3das.noeska.com - create adventure games without programming

Hallo Noeska,
The solution of your problem depends on the details you want to implement. It seem to me that you want to have your own data structure in memory for rendering but handle the loading/saving of different file formats comfortably. Is that so?
Traude

@traude: yes i want a basic structure in memory independent of the way it is being rendered, loaded or saved. And having multiple fileformats in one class is making things cluttered, so i split them up in one class per fileformat. That would also make addition file formats easier.

_________________
http://3das.noeska.com - create adventure games without programming

This problem emerges very often. I have two different solutions for you:

1) A solution made for a modeller, that does exactly the same what you want:
In this case I have a rendering object (TObject3D), that employs specialized objects for loading, which fills in the data structure that my TObject3D hands over to it (Attention! The parameters must not be dynamic arrays, it works only with pointers or lists).

Loading procedures would also be able to do this job. But if you load more complicated data, it seems to be better to have a loading object with short lifetime. With this solution type casting is not necessary. Below you can see the method where two different loaders can be called.




2) A solution made for a texture object, that can call several external loading procedures. Below you can see one of the internal methods. As the data is a little bit more simple than the data of a complicated 3D-object, it can be loaded in one big procedure (although I think for JPEG I would suggest to take a loading object for providing a better organized structure for the loading process):