Gmax for FSX??

[Shaka 2]

>How about FSDSv3? Will the capability remain to use it to>full potential with FSX, or is that something that Sinclair>and Abacus will have to address?>>Pete S.I think that we might not be able to use it directly, but we can still export the project as an .X file and then "hopefully" load that into a future makemdl.exe, which is how I do it now anyway.- Martin

[n4gix 4,947]

>Hi Bill,>>Yes I do model, and yes I have used both of those programs.>However, I think you're misunderstanding. If there is>'nothing' that can be done with them, then why do they not>support lighting palettes, etc.? As a whole, the programs fall>down because they do not support a lot of what goes into>modelling an airfield. Lighting is a key factor, and should>ultimately be modelled since it performs a key navigational>function, not only for nighttime, but for low-visibility.>That's the beef!I'm not at all sure what you're driving at, since "lighting" as such is controlled/supplied by the sim, not by the modeling program or the actual .mdl files produced.Unless you're talking about using the program to render a texture to be used as an _LM.bmp file, I'm afraid I don't see what you're driving at...No matter though, as this isn't the forum for such a discussion in any event... ;)

[Bachian 10]

I realy would like to have Gmax for FSX too, it's an excellent tool and more than enough features for FS. And best of all, FREE!Bachian

[Guest DC-9]

Hi Bill,No, what I'm getting at is, you aren't able to depict in Gmax/3DS Max different classifications of lighting. For instance, Multigen has what is called a lighting 'palette'. It allows you to choose which type of lighting it is, the vectors for the light direction, the color, the intensity, if it flashes, rotates, or whatever. Understandably the lighting is controlled by FS itself, however, the exporters provided with for FS, do not provide the basic elements in order to accomplish those tasks without an appreciable amount of editing of the coding, etc. All of this should be available in the modelling environment such as 3DS Max or Gmax. Not to mention, the support for other options such as pavement markings, airfield geometrics, etc... The only thing I see the 2 modelling programs good for are essentially to make 3D objects such as buildings, none of the other elements in an airport environment are even given any thought to the use of these programs for support. :/ This is a rather complex issue, and I really feel the problem should be addressed this time around, not to mention, the corrections made to the lighting modelled in FS itself. Don't get me wrong, by no means is this an 18 million dollar Level D simulator, but these basic elements are not difficult to simulate in terms of what GPU's are now capable of doing. IMHO, the runway lighting in FS2000 looked better than FS2004 minus a few color issues...Allan

[n4gix 4,947]

I now see where you're driving... ;)The problem is that that many (if not most!) of those parameters aren't part of the .mdl file at all, but are set/stored in disparate .bgl files. How could a "generic modeling program" such as Max or GMax handle such?What you would like (as would many I suspect!) is a "unified, custom program" that would handle all of these features seamlessly, via a common GUI.I believe that such a "Swiss Army Knife" type of modeling environment would only be achievable if a completly new pardigm for FS were developed; one which had such a goal in mind from the outset. Unfortunately, such a paradigm shift would irrecovably break backward compatibility.I will be the first to admit that I too get frustrated by having to resort to a dozen or more separate tools to accomplish the end goal, and would love to have a customized CAD package that would tie everything into one, unified GUI.

[Guest DC-9]

Hi Bill,Yeah, having 10 or more different tools is just a real poor way of doing things I feel. I suppose it wouldn't really affect the backward compatibility of things given that the previous still were left intact until scenery developers had the opportunity to update things a bit. Ultimately, I think having such options would be wonderful, and allow the full development of lighting systems, etc. I don't know how you feel about this, but all too often, I see people complaining of FPS on their systems. I think the truth of the matter behind this is, people expect too much out of a computer. They want developers to basically load the system down with unecessary objects. Of those, for instance, 3D edge lights. No pilots that I know of use them as a functional part of navigating on an airport, or even care what they look like and spend time looking at them; only that they light up at night to serve the navigational function. It's basically a waste of resources, and people wonder why their FPS is so low. Basically what I'm saying is, modelling a light in 3D is not modelling a lighting system in its entirety. Another thing people really have the misconception about is, multi-million dollar simulators do not have or have the resources to support the detail modelled which is in FS; they think they do, but in fact they do not. They're pretty plain and generic in terms of visual content. It's no wonder they're able to maintain a high FPS... I just think it's pretty funny to see just how people 'think' things really are out there. When in reality, what they believe exists in these simulators does not exist; the only difference is the use of calligraphic projects which provide for sharp bright lightpoints. Recently, there's been some development in the use of raster based systems, but it hasn't come far enough along yet to be approved. When that happens, you'll see a tremendous cost cut in visual systems.Anyway, getting back to what I was saying. :) It is frustrating to have to use 10 tools to accomplish one goal, and feel it's really unecessary when all of it could be handled by one program to accomplish the same task. It may cost the developers of FS a bit more to put out, but in the end, I think they'll find a lot of satisfied customers and will open the architecture for FS more. I don't think it would be too difficult to do either; just adding the additional code into a compiler, and allowing editable attributes in 3DS/Gmax wouldn't be difficult.Allan

[FlyingsCool 3]

I agree. There was an MS blog on this subject a few months ago, or perhaps it was one of the videos at Channel 9 or whatever it is called.The gist of the discussion was: Developing tools takes resources. In the past, the development staff concentrated on features, and spent the bare minimum to make basic tools. In fact, I believe the speaker suggested that they wish they had the tools that are available now when they were first developing. So they said that this time around they planned to spend more time developing tools up front, believing that there would be a great time savings on the back end. This would nevertheless impact feature development, but, in the end, they felt the tradeoff would be worth it.I don't know if these tools will be made available through the SDK's or not, or, if, in the end, they really are better than what is available now. I, too, wish there was a better all around tool. But these things don't come for free. I would not expect to see what you are asking for. That, I think would cost a not insignificant amount of money to develop.But let's at least hope the new SDK goes beyond what was available in the past. Based on all the discussions I have read, I really think MS has realized what a benefit third party development is for promoting their product, especially when so much of that development is available for free to the public. I believe it really does extend the life of a product well beyond its normal bounds, especially with the availability and connectivity of the web.Thomas[a href=http://www.flyingscool.com/FC_StartJava.html] http://www.flyingscool.com/images/Signature.jpg [/a]I like using VC's :-)