project structure and specification of model placement

[lmoelleb]

Yes, but it still leaves the problem with the textures for non-generic libraries.

Currently my tool support the concept of a "Verbatim File". A verbatim file is a file being copied directly to the generated scenery. Each verbatim file has a type, one of wich is "Texture" (another is a verbatim BGL file simply being copied without being interpreted). Typically we store the verbatim files next to the actual model node, and it "kind of" works OK, with the following exceptions:
1) It makes the tree a bit messy, as we have at least two entries per model (MDL and at least one texture). I would like to see the textures under the model.
2) Shared textures are either missing from all but one model, or stored in all of them (my tool accepts it, as long as the files are indentical).

We already have the missing texture reports etc, so it is working out, but I would prefer something better.

Basically I have thought of two options:
1) Store all textures in a single location in the tree, then provide GUI funtionality automatically jumping to the used texture allowing the user to "kind of" maintain control

2) Store the texture under each model. When generating write them to disk - if an identical texture has already been written, use it no matter the name (changing the texture name in the MDL before writing it to BGL). If another texture has already been written with the same name, change the name of this texture and update the MDL.

I beleive mostly in 2) as it ensures big projects with many developers will not create a mess for each other, even if they happen to use the same texture name. I also beleive simple tasks as ensuring textures do not clash is something computers should deal with, not users. It is a bit less deterministic what is written, but I do not care about that. Some GUI might be needed to help updating a texture used several places - but that is a GUI problem, not a data model problem.

Third party libraries of course prevents you from changing model name etc, but if you write those first you ensure that their "texture" gets the correct name, and your model will simply reuse the textures if they happen to be identical.

 

[arno]

Hi Lars,

I do not really see why we want to show the textures in the models list. Of course we need to know about them when packaging the scenery, but when creating the scenery I don't really care about the textures used. That is something I deal with when designing the 3D objects and later when packaging the scenery. But when I place the objects, I don't care.

So in my view it can just be an option somewhere in the tool that generates a list of used textures (per model if needed). But I don't think that is something that needs to be displayed in the tree view all the time.

 

[lmoelleb]

Hi Lars,

I do not really see why we want to show the textures in the models list. Of course we need to know about them when packaging the scenery, but when creating the scenery I don't really care about the textures used. That is something I deal with when designing the 3D objects and later when packaging the scenery. But when I place the objects, I don't care.

So in my view it can just be an option somewhere in the tool that generates a list of used textures (per model if needed). But I don't think that is something that needs to be displayed in the tree view all the time.

If I add a model I need to add the textuers as well, if not the other teammembers would not get the texture files and have white buildings when testing the scenery.

Why should the tool not package the scenery? My current tool is doing this, including readme file (verbatim), and a generated location file in HTML and KML showing the location of all objects etc (pulled from the tree structure with a few options to override position inclusion). Given the simplicity of doing this, I do not see why we should skip this. If it is not done by the tool, it would mean it is a manual task which is not repeatable - this is pretty much the worst situation you can be in when it comes to release cycles.

And my current tool does not give me a list of textures used - it gives me a list of textures missing... hmm, good point, I should add "textures not used" but that is trivial to do.

 

[arno]

Hi Lars,

Now, I get the point. It is only an issue due to the server-client structure. When working standalone on a PC it is no issue.

I am not saying it should not package it, but that is something that can happen in the background. The designer does not have to see which textures a model uses when he is just placing it. That only becomes important when it needs to be distributed again.

 

[scruffyduck]

I wonder if it is worth identifying those things that are needed when working in a client/server mode with a team of designers.

I suspect that the majority of users will be using the tool in stand alone mode.

I think it might be helpful to understand the functionality which is required for each mode - even though implementation and coding issues may be 'trivial'

 

[lmoelleb]

Personally I do not see any significent difference (besides the actual server connection obviously).

For example textures I would want in standalone mode as well. Arno might only deal with textures when he create the model and when he package the scenery, but even working alone I would not want to do this - I only want to deal with textures when I create the object, not when creating the package - I am waaay too lazy for that.

I also want the reports to tell me what is wrong, not how things should be. So a list of textures missing I can use, a list of textures that should be there requires me to go and check it manually (or write a new tool to do it). Checking is a rather trivial and boring task - the ideal job for a computer.

 

[arno]

I am not saying the tool should not know (it should know to draw the 3D preview anyhow), but I don't think we need to bother the designer with it all the time. When I am working on a scenery and placing the objects, I do not care which textures they use. I am only positioning objects at a certain latitude and longitude. So I do not want to see a complete list of textures in the GUI during that moment.

As a designer I only need to know about them once I want to generate or release my scenery. And once I want to alter some textures in the 3D object (for example to add seasonal textures). I see this as special actions anyhow, so the texture should be listed somewhere in the GUI elements used for these actions.

As discussed in the other thread, I think we should try to keep the GUI as simple as possible. As we don't want to scare the beginning scenery designer. And trying to put all the information in one tree view of the models is not what I call simple.

 

[lmoelleb]

I am not saying the tool should not know (it should know to draw the 3D preview anyhow), but I don't think we need to bother the designer with it all the time. When I am working on a scenery and placing the objects, I do not care which textures they use. I am only positioning objects at a certain latitude and longitude. So I do not want to see a complete list of textures in the GUI during that moment.

How do you then propose to handle the textures? We need a GUI to add and remove them, and we need a way to easily identify the textures for a specific model so updating it is easy.

As a designer I only need to know about them once I want to generate or release my scenery.

And here is where we differ. I do not want to deal with them at all at that stage. I want to deal with them when I make the model or change the texture, not when I generate.

And once I want to alter some textures in the 3D object (for example to add seasonal textures). I see this as special actions anyhow, so the texture should be listed somewhere in the GUI elements used for these actions.

This is what I refered to as a transformation in my tool, but the name is a bit unfortunate as it clash with the transformations in the model itself. These transformations obviously belong to an object, hence I simply have the transformation hanging under the model they transform. By allowing several transformations under each other full flexibility is preserved.

As discussed in the other thread, I think we should try to keep the GUI as simple as possible. As we don't want to scare the beginning scenery designer. And trying to put all the information in one tree view of the models is not what I call simple.

It is however what I refer to as simple. I do not call separating connected information to several parts of the GUI simple.

 

[arno]

How do you then propose to handle the textures? We need a GUI to add and remove them, and we need a way to easily identify the textures for a specific model so updating it is easy.

What do you mean with to add and remove textures? As I see it an object has some textures, but we are not going to add or remove textures, that is something you do in a tool like GMax. Adding the seasonal textures is more a kind of flag that is set on the object, you should not have have to add all individual textures for that.

This is what I refered to as a transformation in my tool, but the name is a bit unfortunate as it clash with the transformations in the model itself. These transformations obviously belong to an object, hence I simply have the transformation hanging under the model they transform. By allowing several transformations under each other full flexibility is preserved.

That sounds logical. But I don't think the GUI that shows your objects available for placement, should also allow you to do all kinds of tweaks (or transformations) on those objects. I see that as a seperate functionality. For example there could be a tree view that lists all objects you can place (own objects, generic FS objects, etc). When you want to tweak your own objects (can tweak the generic ones of course), that can be done from a tweak GUI or so (by selecting a menu item or so). As these are two seperate tasks, I don't think we should try to put that all in one GUI element.

 

[lmoelleb]

What do you mean with to add and remove textures? As I see it an object has some textures, but we are not going to add or remove textures, that is something you do in a tool like GMax. Adding the seasonal textures is more a kind of flag that is set on the object, you should not have have to add all individual textures for that.

I am taking about adding the actual texture files to the project along with the MDL file. In a perfect world I would actually add a GMax model and a PSD file, but for a start, we probably have to settle for an MDL file and the BMP file.

That sounds logical. But I don't think the GUI that shows your objects available for placement, should also allow you to do all kinds of tweaks (or transformations) on those objects.

Why not? You can obviously place both the tweaked and untweaked version.

I see that as a seperate functionality. For example there could be a tree view that lists all objects you can place (own objects, generic FS objects, etc). When you want to tweak your own objects (can tweak the generic ones of course), that can be done from a tweak GUI or so (by selecting a menu item or so). As these are two seperate tasks, I don't think we should try to put that all in one GUI element.

How would you model the GUI in a case where you need to place versions of the model with different tweaks?

 

[arno]

I am taking about adding the actual texture files to the project along with the MDL file. In a perfect world I would actually add a GMax model and a PSD file, but for a start, we probably have to settle for an MDL file and the BMP file.

OK, I guess I have to get used to that client/server model . Looking from my perspective this tool does not need to know about PSD source textures, etc. All information about the used textures is in the MDL file already. The only thing needed is to locate where these (DXT) textures are stored on disk, based on the name in the MDL file.

But when I look from your perspective (so using it to distribute all sources between different designers), then I understand what you mean. In that case the tool indeed needs to know about all source textures as well (and probably needs to know if they need to be converted to DXT1 or DXT3 when generating the scenery).

I am only a bit worried that these features, that will only be used by maybe 1% of the users in the end, have a lot of impact on the GUI we end up with. I think we should try to hide the things that most people will never use when possible (without making it impossible to use by those that need it of course ).

Why not? You can obviously place both the tweaked and untweaked version.
How would you model the GUI in a case where you need to place versions of the model with different tweaks?

When you start to tweak a model I see it as a different model afterwards. So the tweak and untweaked become two objects then. They should then both show in the list of available objects. So tweaking an object is like adding a new object to your "object library", only it is based on a current object and not loaded from a new MDL file.

 

[lmoelleb]

OK, I guess I have to get used to that client/server model . Looking from my perspective this tool does not need to know about PSD source textures, etc. All information about the used textures is in the MDL file already. The only thing needed is to locate where these (DXT) textures are stored on disk, based on the name in the MDL file.

Please do not focus too much on the client/server part. Considering the texture as part of the project is a benefit to client/server, but it is in no way the main reason to do it. You want a scenery project to be self contained.
Think of it is terms of Visual Studio. Visual Studio allows you to add extra files (bitmaps, text files, etc) to your project. You can then specify that these extra files should be copied to the output directory when building. Why? because Visual Studio is not just about compiling your source code. It is about managing the solution. Why should a scenery tool not work this way?

But when I look from your perspective (so using it to distribute all sources between different designers), then I understand what you mean. In that case the tool indeed needs to know about all source textures as well (and probably needs to know if they need to be converted to DXT1 or DXT3 when generating the scenery).

It would be nice later on, but for now let's just stick to uploading the texture file in the needed format.

I am only a bit worried that these features, that will only be used by maybe 1% of the users in the end, have a lot of impact on the GUI we end up with. I think we should try to hide the things that most people will never use when possible (without making it impossible to use by those that need it of course ).

It will be used by anyone adding an MDL file with a texture. And if you do NOT add an MDL file or a texture, you will not see it in the tree, so I doubt it will bring much confusion. I just hope we can find a better way to include the textures in the tree than I have, but I can't see an obvious solution at this moment.

When you start to tweak a model I see it as a different model afterwards. So the tweak and untweaked become two objects then. They should then both show in the list of available objects. So tweaking an object is like adding a new object to your "object library", only it is based on a current object and not loaded from a new MDL file.

Any reason not simply to display the tweaked object as a child of the parent object in the tree? That makes it clear what it is, and which model you would need to update if you have changed the source MDL file.

 

[arno]

Hi Lars,

I have done thinking on this and it probably makes sense to keep the tweaked versions as childs of the untweaked ones (although they are two completely different models as seen from FS).

For the adding of the textures, what do you think about a scenario like this. When the user wants to add a new object he takes the following steps:

• Indicate that he wants to add a new object (menu item, right click on tree somewhere or something like that).
• He gets an dialog where he can select his object, for example the MDL file or the BGL file containing it.
• This object is then read and all textures found in the file are listed.
• The user can now indicate where these textures are (selecting DXT texture file, or (later) also PSD source files.
• This information is then stored with the object, but I don't think it needs to be displayed in the tree of available objects to place. When the user wants to edit or view this information again he should be able to get the properties of the object somewhere. In this dialog he would not only see the textures, but also other information like the copyright text/IFST information (like MakeMDL version used to compile), bounding box, statistics and other relevant properties.

 

[lmoelleb]

Arno,

I originally considered doing something like this for my own tool, but dropped it again due to time constraint, as well as some usecases I was not sure I could fit into it easily.

The main concern was handling textures shared between multiple models as well as textures used by BGL tools not parsed by the tool (so it would not be able to find the texture name). Hence I ended up simply adding the textures to the tree and report missing textures for placed models only.

 

[arno]

The main concern was handling textures shared between multiple models as well as textures used by BGL tools not parsed by the tool (so it would not be able to find the texture name).

If you simply add the textures to the tree view, do you not have the same problem with shared textures? Or do you just add all textures on one big pile there (not by object)?

About the other BGL files, I see that more as a challenge . Adding support for reading older BGL files (or API macros) is something I certainly want to do, as that would also allow us to convert those old objects to the new MDL format.

 

[lmoelleb]

If you simply add the textures to the tree view, do you not have the same problem with shared textures? Or do you just add all textures on one big pile there (not by object)?

Basically this is not enforced in the tool - you can do both. I even allow the same texture to be added several places - as long as the texture files are identical it will not complain, but if you have two different textures with the same name you will get an error. This was done to allow you to store the texture with all models where it was needed, so deleting a model no longer used would not accidentally result in a missing texture from another model. Obviously some GUI allowing to update the texture across all nodes should then be added - but I never got around to it. I guess it never helped that I was not sure I shouldn't return to my original plan and have a single object for the texture, and then link it several places.

About the other BGL files, I see that more as a challenge . Adding support for reading older BGL files (or API macros) is something I certainly want to do, as that would also allow us to convert those old objects to the new MDL format.

The code I send you can already do this to some extend - we have a lot of FS2002 source models in our project, and they are obviously written in FS2004 format. It only supports streight GMAX export (no tweaking) without animations, but I suspect it would not be hard to get those API things supported as well - the decompiler is pretty standard stuff.

 

[arno]

The code I send you can already do this to some extend - we have a lot of FS2002 source models in our project, and they are obviously written in FS2004 format. It only supports streight GMAX export (no tweaking) without animations, but I suspect it would not be hard to get those API things supported as well - the decompiler is pretty standard stuff.

Yes, I am slowly working through your code. Learning a new language and understand someone elses code at the same time does not go that fast . I hope I can expand it afterwards for older BGL files and API/SCM macros.

 

[lmoelleb]

Yes, I am slowly working through your code. Learning a new language and understand someone elses code at the same time does not go that fast . I hope I can expand it afterwards for older BGL files and API/SCM macros.

Yes, it takes a bit if time to get rid of all the bad habbits you pick up as a VB and C/C++ programmer.

As far as I can see, we live something like 30km apart - so I could simply demonstrate the program for you, and go though my current implementation (and the things I would like to have done better). Drop me an email if you are interested.