Sign in to follow this  
Guest GerrishGray

Object becomes a box from distance

Recommended Posts

Hello,I am placing some objects from the object library like fire trucks and fuel trucks however some of them when seen from a distance they become a plain color box and if we get closer they turn back into the actual object shape and some of them if we get very close they become tiny onesAny idea why this strange this is hapening?ThanksMichel

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Sounds like the "draw distance" for the low poly "box" model might need to be set to a further distance so that the low poly "box" is only drawn when you are so far away you would not notice it. Could you post your code for the above? as it's hard to give you a good answer with out looking at the library calls. that might help with your second problem as well. Dan

Share this post


Link to post
Share on other sites

Hi Dan,Here is the code from the Lirbary Object Fire Truck that is turning into a box when I get a little far from it and then it becomes very tiny if I get very close to it; MACRO: Fire Truck 1 Area( b 33:49:12.986939 35:29:26.597339 20 ) RefPoint( rel :noObj 0.100000 33:49:12.986939 35:29:26.597339 v1= 37040 v2= 32767 ) RotatedCall( :rot 0 0 21.69 ) Jump( : ):rot CallLibObj( 0 C545A2A4 11D2E2EC 1000849C 2AE60C5A )Return EndAThanks! Michel

Share this post


Link to post
Share on other sites

Nothing to see in that code (expect a missing lanel noObj again).I think it is just some code that is in the object library then. Is it a default MS one?Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi Arno,Yup I think those are the default ones because I do not need to install any texture for them in FS and they look very basic and fps friendly. Strange because I placed some baggage carts as well from the library and they show fine from far and close.Only the fire truck and the fuel trucks turn into a box when I am a little far from themCheers!Michel

Share this post


Link to post
Share on other sites

I think I tested some of the default MS objects one day and noticed the same then. But I can't completely remember and as long as the distance at which it becomes a box isn't that small I don't think it's a problem.The only solution to solve it would be to change the library, but because it is a default one that's not a very good idea to do.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Oh I see. Actually I picked the default library because they are fps friendly. Here are screnshots of the FS phenomenon with those objectsCheers :)Michel

Share this post


Link to post
Share on other sites

hello michel! or salut michel!those macros have probably been created with a LOD switche as we use in Gmax. Perhaps are they used in a dynamic scenery somewhere?If it'm right, you can't do anything :-fume Good luck!

Share this post


Link to post
Share on other sites

Salut :)I do not know if they were used in any dynamic scenery but I think they are the default FS2002 object libraries. I think you are right about the LOD thing. Too bad it is hapening because I could have placed many without frame rate impact :/ oh well I will have to do mine in GmaxCheers!Michel

Share this post


Link to post
Share on other sites

Faced with the very same problem, I replicated model of the trucks in gMax (they are rather simple) and covered with M$ textures. Frankly I like only the snow plow and the pushtruck. Firetruck deserves to be better.Ted

Share this post


Link to post
Share on other sites

I agree that is exactly what I will be doing then I will find how to put them in an object Lirbary :)CheersMichel

Share this post


Link to post
Share on other sites

Hi guysOnce again this is FS Architect -generated code and contains the same errors as the other example we have been talking about. For a start, there is no PerspectiveCall() and this is perhaps what causes the scaling problem. Check the other thread for details of how to put this right.There may be other causes for the loss of texturing beyond a certain range, but let's get the calling code right first ...CheersGerrish

Share this post


Link to post
Share on other sites

>There may be other causes for the loss of texturing beyond a >certain range, but let's get the calling code right first Hi Gerrish,Yes there may be other causes. Some time ago I tried to decompile one standard library BGL. However, with labels "without meaning" it was hard to follow the code and I gave up. I did not looked to the "calling" BGL as used by MS. I tried my own simple calling BGL, with a proper PerspectiveCall. May be (?) MS uses a calling method where multiresolution is decided in the calling part of the code.Regards, Luis

Share this post


Link to post
Share on other sites

Hi LuisThe multi-resolution part of the default MS library objects is embedded within the objects themselves and does not need any special calling sequence. Did you have a problem when you called the objects with your own calling macros?The loss of texturing on gMax-created objects beyond a range of about 6km has a well-known cause arising from a mistake in makemdl.exe - the textures for 3D objects are incorrectly defined as aircraft textures. Another possible cause is incorrect use of the 'texture-size' parameter required in the 'floating point' texture definition list. But it seems that there might be some other causes as well in some circumstances, possibly resulting from an interaction between the internal frame rate optimisation code that has been added to the scenery engine in FS2002 and factors such as visibility ranges and the 'image power' parameter in the Area() block header. CheersGerrish

Share this post


Link to post
Share on other sites

>Hi Luis >>The multi-resolution part of the default MS library objects >is embedded within the objects themselves and does not need >any special calling sequence. Did you have a problem when >you called the objects with your own calling macros? Hi Gerrish,Yes I had the same problem as depicted in the images shown here by Michel. I noticed that multi-resolution was embedded in the objects, as you say, but I did not investigated much. I think we are referring to FS2000 libraries and so ... >The loss of texturing on gMax-created objects beyond a range >of about 6km has a well-known cause arising from a mistake >in makemdl.exe - the textures for 3D objects are incorrectly >defined as aircraft textures. Another possible cause is >incorrect use of the 'texture-size' parameter required in >the 'floating point' texture definition list. But it seems >that there might be some other causes as well in some >circumstances, possibly resulting from an interaction >between the internal frame rate optimisation code that has >been added to the scenery engine in FS2002 and factors such >as visibility ranges and the 'image power' parameter in the >Area() block header. ... FS2002 causes are not responsible. However I am not sure about what you mean by 'image power' in the Area() block header.Kind Regards, Luis

Share this post


Link to post
Share on other sites

Hi again LuisI have not checked them all, but at least some of the default library objects that existed in FS2000 have been re-coded for FS2002 using gMax-generated code, so they could well be affected by the 'aircraft texture' error.IMAGE POWERThe final parameter in an Area() call is correctly named 'image power', not 'range' as in the now-outdated SCASM documentation. Its units are apparently %, not kms, and in the BGLC macros this value defaults to 100% if not explicitly set. It is not clear, however, exactly what effect this 'image power' actually has, although it may still effect the range at which the object is loaded into the current object database? Generally speaking, using a value of 20 or 22 (% not kms) as in the traditional version still seems to work satisfactorily in most cases ...What I believe I have observed is that objects can still be displayed beyond their apparent maximum visibility range, if that range is set to a low value, but lose their texturing in the process. I don't fully understand this behaviour and haven't done enough testing to be sure of when it happens (or even to be sure that it really does happen!), but when sorting out some problems for a new designer, this was one of them and I got the impression that it was caused by setting the image power and/or the v1 value too low. I gave him a corrected code version that corrected several apparent errors at once, and so, unfortunately, I missed the opportunity to test it correctly and eliminate each possible cause one step at a time ... I should have known better, but I wanted to help the guy quickly without confusing him!RegardsGerrish

Share this post


Link to post
Share on other sites

Hi,I can't pretend to have understood all of what has gone before, however do I get the message that scenery containing aircraft "parts" is not visible beyond 6km?I have been trying to figure why I can see the runway landing strobes beyond this limit, but my rotating gmax beacon (with landing lights) doesn't become visible until I am closer that 6km....Geoff

Share this post


Link to post
Share on other sites

Hi GeoffTo try and clarify the 'aircraft texture' problem with gMax/makemdl.exe:-When you design a building or other similar scenery object with gMax, the compiled code created by makemdl.exe flags the list of texture bitmaps used as being for an aircraft model rather than a building model. This results in the textures not being used beyond a range of 6kms - the building (or whatever) is displayed with just it's underlying 'material' rather than textured surfaces when it is more than 6km away. There are several ways of curing the problem, e.g. :-[ol][li]Capture the .asm code from makemdl.exe and change the value of the parameters in the texture definition list from 1 (aircraft) to 6 (building). This is the CORRECT solution but admittedly needs a little knowledge of BGLC coding. I think you will find the details on Arno's very helpful web site though (is that right, Arno?) and it isn't too difficult.[/li][li]It has also been discovered that the building(s) will display correctly if you place a ground polygon underneath them with at least one very long side! But this is a crude and 'dirty' fix.[/li][li]Use an alternative tool such as FSDS2.[/li][li]Do your scenery design a different way altogether, such as coding in SCASM by hand (it's not really so difficult), or even use a free design tool such as EOD to do the basic 'drawing' of the model and then translate the old-fashioned SCASM code it produces into the up-to-date floating point version.[/li][/ol]For gMax users, solution 1 is the right way to go for the time being (i.e. until MS correct the mistake in makemdel.exe). Buying FSDS2 (or NovaSim once the full version is released some time early in the New Year) is the best choice for those wary of the gMax learning curve - and might produce even better (and quicker) models than gMax. My personal preferred solution (#4) of coding by hand, or translating code generated in some other way, is admittedly only for us 'codeheads' really, but quite a lot of guys find it fun and you can soon learn the rudiments by reading this forum and the various tutorials available, and then asking for help as necessary !!!Solution 2, however, is NOT recommended for anyone who wants to make a decent job of their designs and keep their self-respect!Hope this helps a bit!GerrishP.S. Hi Arno - hope you are keeping well and enjoying your travels between home and Belgium !

Share this post


Link to post
Share on other sites

Hi Gerrish,Yes, everything OK here :). Luckily they also have internet here :D, so I can follow all interesting discussion and in the evenings I can work on my PC here.Now back to the question/problem.Your point 1 should work this way, and it is not hard to change that piece of the code. Only open the _0.asm file and in the texture list (that's at the top of the document) replace the TEXTURE_AIRCRAFT types by TEXTURE_BUILDING. After that it should work fine.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi Gerrish,Thanks for all the information, I will give it a try...Geoff

Share this post


Link to post
Share on other sites

Just last question. Make it two questions ..... What is the proper procedure (syntax) to recompile *.asm file by hand? Do both files need to be recompiled or just the one _0.asm with the change? Thanks Ted

Share this post


Link to post
Share on other sites

You need them both.Let's assume your project is called test.Then the first file test.asm contains the code for the placement of the object. This file includes the second file, test_0.asm, which contains the actual code for the object.So to recompile I type in DOS: "bglc test.asm" and then I get the new BGL file (I have put BGLC on my path to be able to compile easy, but you can also drop the file on BGLC if you prefer the windows way :)).Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

On the original question of the Fire/Fuel truck objects.Unfortunately these are just bad objects. They were bad in FS2000 (switching to crude boxes at far too short a distance) and they have major scaling problems in FS2002. It is the same library in both cases and uses TexPoly for the objects rather than the newer code.FS2002 seems to have problems with library objects that have a scale of 1.0It gets confused and at some times displays it far too small or too large. Most FS2000 vehicle objects are scale 0.5 and don`t have any problem. The Firetruck and Fueltruck (and a couple of the ships) are 1.0 and have erratic display problems.These trucks only have 3 Lods but they are set to switch far too soon. About 6 pixels/m and 1.5 pixels/m

Share this post


Link to post
Share on other sites

Hi MartinThe original problem here was caused, I believe, by an incorrect calling sequence for the library object, omitting the essential PerspectiveCall() step.I do not think that there is any general problem with using scale 1.0 for library objects. There is no logic to this scale, rather than say 0.5, having any particular problem. I have created several thousand library objects with scale 1.0, used by tens of thousands of users, and have had no report of any problem like this.You are certainly right that some of the original FS2000 stock library objects were not quite as well designed as they might have been! I hadn't checked whether they had put this right in FS2002 but I am not surprised when you say not! Many of the other default library objects in the FS2002 scenery have been upgraded to floating point code - what a pity MS didn't put the stock vehicles, boats etc. right at the same time!Keep wellGerrish

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this