Faded taxiway lights........who knows the trick?

[Guest raf]

Thanks Martin,interesting code, even if it's rather different from the one I get once my Gmax file is written in the .asm_0 format. In detail, I've never seen the BGL_FTAG command before. Is it produced by MakeMdl or is it from some handwork of yours?Also, I noticed that, in your .asm file, the command lineBGL_CALL OBJECT_0_BEGINis replaced by INSTANCE_CALL OBJECT_0_BEGIN 0, 0, 0CB60hWhat is this change used for?To cut it short, here's a sample of the .asm_0 code I get, maybe having a look at it will help you to understand where I'm getting wrong.*************************************************************rwylights_temp_top label BGLCODE BGL_BEGIN 0800h ; version = 8.00 MATERIAL_LIST_BEGIN MATERIAL_DEF 0.352941,0.352941,0.352941,0.349020, 0.352941,0.352941,0.352941, 0.000000,0.000000,0.000000, 0.000000,0.000000,0.000000, 0.000000 ; 0 MATERIAL_DEF 1.000000,1.000000,1.000000,0.349020, 1.000000,1.000000,1.000000, 0.000000,0.000000,0.000000, 0.000000,0.000000,0.000000, 0.000000 ; 1 MATERIAL_LIST_END; Alpharwylights_temp_Alpha label BGLCODE ; Node 3 - RotateAroundX transform: BGL_TRANSFORM_MAT 0.000000,0.000000,0.000000, 1.000000,0.000000,0.000000, 0.000000,0.000000,1.000000, 0.000000,-1.000000,0.000000 ; Node 4 - light_nav_grey01 transform: BGL_TRANSFORM_MAT 2660.292236,516.425049,-1.097972, 1.000000,0.000000,0.000000, 0.000000,1.000000,0.000000, 0.000000,0.000000,1.000000 ; Node 5 - Light_nav_Grey02 transform: BGL_TRANSFORM_MAT 0.461670,-0.114318,0.981740, -0.010964,-1.562861,0.008113, -0.929662,0.000000,-1.256364, 1.256316,-0.013639,-0.929626 BGL_LIGHT LIGHT_TAXI, 0.000, 0.000, 0.000, 20, 0.60, 0.40, 0595A5A5Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 1 BGL_LIGHT LIGHT_TAXI, 0.000, 0.000, 0.000, 20, 0.60, 0.40, 0595A5A5Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 2 BGL_TRANSFORM_END ; Transform Light_nav_Grey02 BGL_TRANSFORM_END ; Transform light_nav_grey01(.............) BGL_TRANSFORM_END ; Transform RotateAroundX BGL_END BGL_RETURN***********************************************************

[martin_ktpa 0]

File attached. This is a taxi light I was testing at Meigs. It doesn't work the way its supposed to, the fading rather seems to be influenced by some of directional vector. slew 360 degrees around it, you'll see how strangely it behaves. only thing I did after exporting was replace LIGHT_NAV -> LIGHT_TAXI, the rest is pure makemdl.

[Guest raf]

Thanks so much,I'll throw a glance on your files, but I've seen yet that into the .asm file you sent me the stringINSTANCE_CALL OBJECT_0_BEGIN 0, 0, 0CB60his missing, and the usualBGL_CALL OBJECT_0_BEGINis used.I'd be very curious to understand what this string is used for and - if such a string is of some use about lights fading - how should I do (in Gmax) to make MakeMdl to generate it.Btw: why do you use a 8-sided sphere (i.e. 6 vertex, 8 faces) for taxilights? As far as I know, they should work also if a single plain triangle is used (i.e. 3 vertex, 1 face).Meanwhile, I'll test your files in FS and will let you know.Raf

[arno 1]

I have seen this difference between INSTANCE_CALL and BG:_CALL before. Maybe it has something to do with the version of MakeMDL that is used.INSTANCE_CALL is the same as the SCASM RotatedCall command, so it could also be that it depends on if you enter a rotation heading or not. Looking from this source, is seems that a variable is driven the rotation.

[martin_ktpa 0]

INSTANCE_CALL OBJECT_0_BEGIN 0, 0, xxxxxx is used whenever exporting with a different heading. If left default (000 degrees), makemdl writes BGL_CALL OBJECT_0_BEGIN.The code that Makemdl generates from LIGHT_X assigned objects is the same no matter if you use a triangle or a 512 sided sphere, it will always write only the same coordinate data to the _0.asm file, ignoring the objects geometry. Makemdl will take longer process, but it will make no difference in FS performance, the _0.asm and BGL are the same. If your Gmax airport is huge I would recommend using small objects just to keep Gmax's OpenGL window at a workable speed.I haven't had time to test this further, but you might want to play with the objects pivot since in FS the light seems to have a directional vector as it shines brighter in a certain direction.The solution to the whole problem is within this line alone I believe. When I use LIGHT_NAV in Gmax, export and change the LIGHT_NAV to LIGHT_TAXI by hand I get this:BGL_LIGHT LIGHT_TAXI, 0.017, 10.499, 0.005, 20, 0.60, 0.40, 0FF27FF17h, 0.000000, 0.000000, 1.000000 ; source poly num = 1Now... when I use LIGHT_TAXI in Gmax and export I get this:BGL_LIGHT LIGHT_TAXI, 0.000, 0.000, 0.000, 20, 0.60, 0.40, 0FF27FF17h, 0.000000, 0.000000, 1.000000 ; source poly num = 1See how there are some different parameters not being written when using LIGHT_TAXI in Gmax... I have no idea why that is and what they are used for but I think this is where we will eventually find the solution.

[arno 1]

The only difference between the two BGL_LIGHT commands seem to be the first three, and these are the position of the light. So it seems that you placed it somewhere else. All the others look the same.From all the tests I have done until now, it looks like the vector paramters do not work. You can not adjust the visibility of the light with it (I tried to make some lights that are only visible from one side).

[martin_ktpa 0]

Ok, but does your makemdl actually write the first 3 parameters when exporting it as LIGHT_TAXI? mine does not, even when I don't touch the object (position). The visibility from one side only is either a bug or something we can change somehow. Otherwise this LIGHT_TAXI doesn't make any sense at all...PS: it does somhow "fade" from visible to invisible like a taxi light should, doesn't it?

[arno 1]

I should check at home if it writes them, but I never encounted problems in the past.And about the sense of the LIGHT_TAXI command, I don't know if it is intended to be used in a scenery like this. It could also be that it is meant for the taxi lights of an aircraft or so (remember MakeMDL is both for scenery and aircraft).For me the difference between all the light types are not very clear, as most look exactly the same in the scenery.

[Guest raf]

Thanks all for your explanations about the INSTANCE_CALL (meanwhile I checked the BGLC SDK) and the other commands.Arno: LIGHT_TAXI and LIGHT_LANDING light types are good for runway lights and for unidirectional lights in general. The fact they're visible from one direction only it's not a bug, but it's just the way they're intended to be. Guess even that, if applying a keyframe animation, they might be good for rotating beacons or for a sort of flashing effect too. All the other light types are 360

[martin_ktpa 0]

I'm not sure what FTAG does, but I know there are more FTAG commands besides "Masterscale". I also think it is written based on some makemdl checkbox since not all my source files have it.Maybe LIGHT_TAXI_0 gets rid of the ground lightspot? haven't had time to test it.

[Guest raf]

No, LIGHT_TAXI_1 will.LIGHT_TAXI_0 will get you rid of the lightpoint.Raf

[martin_ktpa 0]

I'm pretty sure now this LIGHT_TAXI is supposed to be used with aircraft MDLs, but since it is the only gmax light that has shows some fading effect it is the best shot. The direction of the light seems to be always towards HDG 0.... You can try other light commands, but I haven't seen any fading effects with them.light_nav * constantlight_beacon_ * blinks"BeaconN" where N= 2,3,4 or 5bright_ * same as self ilumination?light_land_ * spotlightlight_taxilight_recognitionlight_logolight_wing LIGHT_strobethat's it. no others that I'm aware off.

[Guest raf]

Light direction can be oriented if you use a 2D shape (not backfaced) instead than a 3D one. The suffixes _0 and _1 after the LIGHT_TAXI and LIGHT_LANDING commands do work exactly the same way an do produce the same effect.I'll try again replacing all my LIGHT_LANDING commands with LIGHT_TAXI ones and see if some improvement is visible.At the moment I'm carrying on experiments with flashing lights, changing hex values in the IFMSK string and seeing what happens in FS.Raf

[Guest raf]

I'm raising this thread to the top again to update whoever might be interested with the results of my latest researches, and to ask to someone most experienced than me while these researches brought me to nothing once more.I created two sample taxilight files, one using the material special names listed in the MakeMdl SDK (light_nav, light_land etc.) and compiled thru makeMdl), and another one without special names and compiled thru the Fsregen lights procedure. Then I compared the two codes I got and made several manual changes to them in order to see the effect in FS.What makes me puzzled is that there are parameters compiled in a different way by MMDL and FSR, but there's no visible difference in FS.The structure is basically this:BGL_LIGHT LIGHT_NAV, xyz offset, light intensity, linear attenuation, square attenuation, color code, unknown, unknown, unknownWell, you might think that changing the attenuation parameters something should change (I was convinced I found the trick), but I tried values from 0.01 to 5.0 and nothing changes. Even the light intensity parameter seems to be unactive, the sole way to change light intensity is to darken the diffuse color of the light.The SDK says that both attenuation parameters are 'reserved' and 'currently not used', but, if things are that way, why both MMDL and FSR should take the pain to write values for them else than 0.0??FSR does even compile values (else than 0.0) for two of the three 'unknown' parameters, and it allows to change the attenuation parameters.I'm used to think that, if a parameter value is customizable, it should be of some use and should give some visible result in FS, but this doesn't seem that case.Anyone can throw some light on this?

[Guest luissa]

>I'm used to think that, if a parameter value is customizable,>it should be of some use and should give some visible result>in FS, but this doesn't seem that case.>Anyone can throw some light on this? Hello Raf,I read your last post about the problems you describe. I do not use gmax on my modelling so I can not comment on that. When designing Madeira we built a runway illumination with SCASM commands for FS2002. We usedDot( [$AL] 5 [$A2] )for low intensity ligths andLight( m 4 [$AL] 5 [$A2] 40 0.6 0.4 EF 255 255 255 0 1 0 )for brigther lights. And light intensity, linear attenuation, square attenuation, have no effect as you also found. We also had lighthouses with rotating lights and very intense flashing lights (as in http://www.ptsim.com/en/madeira/madeira.htm). When FS2004 came out we tried everything to increase the intensity of the lights but we were not well succed. The only thing that we have done was to make a macro light (light.api). We made an halo.bmp and and a flat square. The flat square is painted with the halo.bmp which is very bright at night. The square rotates so that its painted face allways points to the viewer. And, more important, the size of the square increases with the distance to the viewer. Here is the code for a FS2002 flashing light::flash08 Transform_Mat( a [$X08] [$Z08] [$Y08] 0 0 [$H08] ) Light( m 11 0 0 0 40 0.6 0.4 EF 255 255 255 0 1 0 ) TransformEnd Light( m 4 [$X08] [$Z08] [$Y08] 40 0.6 0.4 EF 255 255 255 0 1 0 ) and the same flsah for FS2004::flash08 Transform_Mat( a [$X08] [$Z08] [$Y08] 0 0 [$H08] ); Light( m 11 0 0 0 40 0.6 0.4 EF 255 255 255 0 1 0 )macro( ../apis/light.api ) TransformEnd Light( m 4 [$X08] [$Z08] [$Y08] 40 0.6 0.4 EF 255 255 255 0 1 0 )We used this light.api macro in the lighthouses but we did not changed the runway lights. If you discover a way of increasing the visibility of lights, we would like to know.Regards, Luis