Emitter Offset

[abax2000]

I try to build a light effect (sequenced strobes) using an effect with multiple emitters, offseted so that you will get a series of lights.

For the time, I am experimenting with a very simple version with just two emitters. Here is the code:
[Library Effect]
Lifetime=5
Version=2.00
Display Name=Hammerfest_3_leadin
Radius=-1
Priority=0

[Properties]

[Emitter.0]
Lifetime=0.00, 0.00
Delay=0.00, 0.00
Bounce=0.00
No Interpolate=1
Rate=1.00, 1.00
X Emitter Velocity=0.00, 0.00
Y Emitter Velocity=0.00, 0.00
Z Emitter Velocity=0.00, 0.00
Drag=0.00, 0.00
X Particle Velocity=0.00, 0.00
Y Particle Velocity=0.00, 0.00
Z Particle Velocity=0.00, 0.00
X Rotation=0.00, 0.00
Y Rotation=0.00, 0.00
Z Rotation=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=0.00, 0.00
Z Offset=0.00, 0.00
Pitch=0.00, 0.00
Bank=0.00, 0.00
Heading=0.00, 0.00

[Particle.0]
Lifetime=0.10, 0.10
Type=19
X Scale=8.00, 8.00
Y Scale=8.00, 8.00
Z Scale=0.00, 0.00
X Scale Rate=0.00, 0.00
Y Scale Rate=0.00, 0.00
Z Scale Rate=0.00, 0.00
Drag=0.00, 0.00
Color Rate=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=0.00, 0.00
Z Offset=0.00, 0.00
Fade In=0.00, 0.00
Fade Out=0.00, 0.00
Rotation=0.00, 0.00
Static=1
Face=1, 1, 1

[ParticleAttributes.0]
Blend Mode=2
Texture=fx_2.bmp
Bounce=0.00
Color Start=255, 255, 255, 200
Color End=255, 255, 255, 0
Jitter Distance=0.00
Jitter Time=0.00
uv1=0.00, 0.50
uv2=0.50, 1.00
X Scale Goal=0.00
Y Scale Goal=0.00
Z Scale Goal=0.00
Extrude Length=0.00
Extrude Pitch Max=0.00
Extrude Heading Max=0.00

[Emitter.1]
Lifetime=0.00, 0.00
Delay=0.02, 0.02
Bounce=0.00
No Interpolate=1
Rate=1.00, 1.00
X Emitter Velocity=0.00, 0.00
Y Emitter Velocity=0.00, 0.00
Z Emitter Velocity=0.00, 0.00
Drag=0.00, 0.00
X Particle Velocity=0.00, 0.00
Y Particle Velocity=0.00, 0.00
Z Particle Velocity=0.00, 0.00
X Rotation=0.00, 0.00
Y Rotation=0.00, 0.00
Z Rotation=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=0.00, 0.00
Z Offset=200.00, 200.00
Pitch=0.00, 0.00
Bank=0.00, 0.00
Heading=0.00, 0.00

[Particle.1]
Lifetime=0.10, 0.10
Type=19
X Scale=8.00, 8.00
Y Scale=8.00, 8.00
Z Scale=0.00, 0.00
X Scale Rate=0.00, 0.00
Y Scale Rate=0.00, 0.00
Z Scale Rate=0.00, 0.00
Drag=0.00, 0.00
Color Rate=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=0.00, 0.00
Z Offset=0.00, 0.00
Fade In=0.00, 0.00
Fade Out=0.00, 0.00
Rotation=0.00, 0.00
Static=1
Face=1, 1, 1

[ParticleAttributes.1]
Blend Mode=2
Texture=fx_2.bmp
Bounce=0.00
Color Start=255, 255, 255, 200
Color End=255, 255, 255, 0
Jitter Distance=0.00
Jitter Time=0.00
uv1=0.00, 0.50
uv2=0.50, 1.00
X Scale Goal=0.00
Y Scale Goal=0.00
Z Scale Goal=0.00
Extrude Length=0.00
Extrude Pitch Max=0.00
Extrude Heading Max=0.00

For testing, I have placed two effects side-by-side: one direct effect placement and an object placement (on which the effect is attached). Both placements are done via ADE.

In both cases, the two emitters are rendered one on top of the other (i.e. the offset of the second emitter is not working).
Strangely when I use the FXTool to check the effect out, I do see the offset, which is not there when the effect is properly placed as above.
I tried also to place the effect with SBuilderX, with the same results: no emitter offset.

Another interesting (and strange) find is that the stock fx_emergencylights.fx , while in FXTool has an offset between the white and red light (as coded), when placed directly on the scene as an effect, is also rendered with no offset.

Could you please test yourself the attached effect and provide some help on these issues?

 

[RicherSims]

I may be wrong (as I do not have time to test at the moment and this is off the top of my head) but try changing Static=1 to 0. Will get back to you when I have more time.

 

[abax2000]

I have tried that with no luck (seems that a light particle is falling to the ground).

As I continue testing, seems that particle offset may give some results.
Still cannot understand why emitter offset is not working (although coded in a stock effect which seems that is not rendering as expected ! ).
I will try to find in the rest stock effects the combination of static=1 and emitter offset use.

 

[abax2000]

Seems that Emitter offset does not work (probably when Static=1).
Particle offset does work with Static=1, but only when particle Type=19; not with particle Type=25.
Don't know why for both cases.

When trying to place the effect (or an object with the effect attached), the final orientation of the line of lights follows a strange logic:
orientation=2x(placement heading)+(particle offset degrees)
So in case particle offset is x=40, y=z=0, (particle offset is 90deg), and your placement heading is 50deg, the orientation you get is 2*50+90=190.
How this come and why, escapes me.

If anyone can verify/comment, would be very helpful.

Edit
The combination of emitter offset with static=0 does not seem to work either.
So, what would be needed to get emitter offset to work?

Could somebody pls check if the stock effect fx_EmergencyLights.fx renders as expected (with some distance between the red and white lights) ?

 

[abax2000]

Besides the issues in previous posts:
emitter "delay" setting seems to be unstable. It has to do with framerate, or what, I don't know.

Is there any tip on this?

 

[abax2000]

It seems that there is no interest in this subject, but nevertheless I post test results for future reference:

Parameters tested are Type (=19 or 25), Static (=1 or 0) and Offset (emitter or particle).

1. Offset (either emitter or particle) does not work with Type=25.
2. Emitter offset does not work also with Type=19.
3. Particle offset works with Type=19.

In this testing, offset was X=200, Y=Z=0, so the angle in the effect's own reference system was a=90. Let's call the heading defined when placing the effect (with ADE or SBuilderX etc) PH. Then:

1. When Type=19, Static=1 and Particle offset used, the in-sim orientation of the line of lights is (2*PH+a).
2. When Type=19, Static=0 and Particle Offset used, the in-sim orientation of the line of lights is (PH+a).

If the lights are sequenced using Delay, correct sequencing is not guaranteed as it seems that delay is affected by frame rates and can fluctuate at render time.

As for the appearance of effects when arriving at the airport the effects are placed:

1. Seems that when Static=1 then the effects may not be rendered.
2. But when Type=25 (and Static=1) the effects will render. The effects will render also if Static=1 and Emitter Lifetime=0.
3. Other effects that do not use Static=1, have no issues of this short.

This was posted in the forums years ago, but seems to be forgotten.

Two final interesting notes:

• In SDK and under Static explaining notes, is written that "Particle offsets do not work on static particles, use emitter offsets instead." Well, it is exactly the opposite: When Static=1 only particle offset can be used, and not emitter offset.
• Several stock light effects (mainly destined for obstruction lights) are of Type=19, which means that they will not render when arriving at your destination. Edit just the Type to "25" and they will be there for you. If they are purely flashing lights (i.e. have "Emitter Lifetime=0"), then they will be rendered anyhow.

EDIT - Use of Controller
In order to get reliable sequencing, tried the use of controller, which indeed gives accurate synchronization.
No quirks observed with controller.
Two notes:

1. Orientation is only dependent on the offsets defined in the controller (X,Y,Z). The placement heading has no effect. This means that you cannot keep a saved controller to use in different airports; you'll have to tailor it for every each case and create a new version.
2. Seems that just as the aircraft passes by the origin of the controller, the effect is not further visible (even if there more lights in front of the aircraft that are controlled by the controller). So it is better to define as origin of the controller the last point that the inbound aircraft will pass (ie. if the controller controls 20 sequenced lights leading to the threshold, place the controller at the innermost light position).

As for the performance issue (i.e. if the controller is more resource-hungry than plain vanilla effect), I have not yet ran reliable tests.

 

[robystar]

Hi,

Good observations!
There is probably interest in your thread alright but I do not think anyone (not me for sure) can give you an explanation.
What I do know is that the same thing occurs with AI when tryiing to add an effect to an attach point of it, but that is probably not applicable to your situation.
The desynchronisation (delays between two effects within one file) with multiple emitters is something I experienced as well when trying to make a missile effect and have the exhaust flame follow the missile itself that was also part of the effect.
Have you tried with a controller?

 

[abax2000]

I was hoping to get this done in a straightforward single .fx file, which seem to me the most lean and elegant solution.
Maybe in more powerful rigs, desyncronization will not be an issue, but it surely is in my old box.

So, first I tried with an effect emitting effects (see here http://www.fsdeveloper.com/forum/showthread.php?t=426851), but no luck either. And this time I have no clue what can be wrong.

Using controller will eventually be the last resort. I was trying to avoid it as I have read that it causes more of a performance hit than just using effects.
I'll give it a shot.

 

[abax2000]

Edited and updated post no6 following Robystar's suggestion to use a controller.

 

[GaryGB]

Hello:

I've enjoyed reading your investigations on the topic of FS special effects recently, and have been too pre-occupied with some time commitments, and some health concerns, to fully refresh my memory on some of the more arcane aspects of working with Effects to the extent that I'd be up to fully grasping what you are working on, and able to contribute something genuinely helpful, so I haven't posted until now.

But please be assured your efforts to better understand how to work with Effects, and your shared insights are greatly appreciated.



I also am not quite sure we yet fully understand all aspects of how the Effect placement offset problem can be resolved.

But with ongoing inquiry and testing, I'm inclined to think we may be able to achieve more consistently predictable results with placement via attachment to a MDL or via XML placement.


BTW: I stumbled across this today while searching through the FS SDK docs for info on "BiasX" and "BiasZ", and thought you might find this interesting as an additional placement control.

http://msdn.microsoft.com/en-us/library/cc526978.aspx#BiasXYZ


FYI: These parameters accept "floating point" values (aka "fractions of a Meter", which IIUC may allow a finer granularity of control.

I'm not sure if the span of values accepted for "floating point" with Bias X,Y, or Z is the same as what IIRC was specified by ACES Doug Matthews with regard to needing at least 6 decimal places to satisfy the value criteria and/or invoke a greater precision threshold within the SDK compiler.

NOTE: The context of that particular discussion was when working with terraced water polygons in ex: rivers that change elevation up/downhill on terrain without triggering the FSX default "rocks-in-water anomaly" (...seen when the "Modified Terrain.Cfg" file is not used.)



Also, another interesting thread with links to discussions on use of Bias X,Y, or Z with "Triggers":

http://www.simforums.com/forums/fuel-trigger_topic22120.html


Hmmm... as I read this info, I'm still wondering if both FS Effect parameters and Effect placement coordinates is based on Meters from a Reference Point, and this has to be correlated with values for Lat/Lon/Alt of placement in the FSX 3D spheroid world model, could a lack of precision in computation of Offset and/or conversion to geographic coordinates be a basis for the recurrent unpredictability being seen when placed Effects are actually displayed in FSX at run time ?


Hope this helps, and Many Thanks for sharing your ongoing R&D with FS Effects !

GaryGB

 

[abax2000]

Most importantly, I hope your health issues are resolved.

Making me read again carefully the SDK part on Bias, it writes that "This bias is not affected by pitch, bank, or headings applied to the base scenery object"; so, this can be related with the fact that offsets within the controller syntax are not affected by the heading used in placement (meaning that XYZ min/max settings in controller are equivalent to Bias and follow the same subroutines).

Which is not the case for particle offset (orientation is affected by placement heading, in a totally consistent and reproducible way, but the logic escapes me). And strangely enough, the orientation result is different when Static=0. Perhaps we stumbled on yet another bug.

Yet the biggest mystery for me is why the emitter offset seems inactive, even in the stock fx_EmergencyLights.fx.

 

[GaryGB]

Hi again:

I'm not sure if this may impact the adjustments you are trying to achieve, but this thread discussed an additional consideration when implementing a BiasX,Y, or Z parameter ex: when placing an Effect via XML code:


"If this element is used inside of a SceneryObject it must come before any instances of AttachedObject, Effect, GenericBuilding, LibraryObject, Trigger, Windsock."

"Just move the whole <BiasXYZ> element so that it appears before LibraryObject-and everything should work"

http://www.fsdeveloper.com/forum/showpost.php?p=29122&postcount=9

[EDITED]

"Bias Z = North/South (LAT axis), Bias X = East/West (LON axis), and Bias Y = Altitude ...viewed from Topdown Mode"

http://www.fsdeveloper.com/forum/showpost.php?p=3907&postcount=4

[END_EDIT]

http://www.fsdeveloper.com/forum/showthread.php?t=809


Your posts thus far have not also shown your XML placement code used to place the Effects under discussion, so I thought I'd mention this important consideration as a reminder when structuring one's XML placement code prior to compilation with FSX SDK BGLComp.



Also, this explanation clarifies something that I've not seen posted elsewhere thus far:

"Attach point effects have a number of problems associated with their use , chief is the offsets are centered to the attach point , meaning the emitter is positioned at the attach point whatever the offset."

"Not a major problem for lights but with regards to ( ex: ) smoke & flame you need to redo the effect without offsets, and for those that use offset emitters, (these) need to be redone so each emitter is on its own attach point ...and multiple attach points are positioned where you need them."

http://www.fsdeveloper.com/forum/showpost.php?p=65726&postcount=3

http://www.fsdeveloper.com/forum/showthread.php?t=9759


Hope this might help !

GaryGB

 

[abax2000]

"Attach point effects have a number of problems associated with their use , chief is the offsets are centered to the attach point , meaning the emitter is positioned at the attach point whatever the offset."

While testing I had also placed an effect on its own (not attached to an object), and saw no difference.

Your posts thus far have not also shown your XML placement code used to place the Effects under discussion ...

All placements were done by ADE.


Would you be so kind to check the stock fx_EmergencyLights.fx?
Just place it (on its own, not attached to an object) next to your threshold and see if there is a small distance between the two lights (as coded) or not.

I also attach the effect I was experimenting with, in case you want to take a look. It is a straight line of three lights with a sequenced flash.

For the time being I settled with a version that uses a controller which gives also a reliable sequencing and synchronization.

 

[GaryGB]

While testing I had also placed an effect on its own (not attached to an object), and saw no difference.

All placements were done by ADE.

While it is good to see that ADE now has the ability to place Effects, the current feature set does not (yet ?) offer the full set of parameter options that are available in the FSX SDK FX Tool, including some which might be used more often to achieve an "offset".


To see the ADE Effect placement XML code for your Effect(s):

* Click your "Effect" placement icon to 'select' it

* Right-click that "Effect" placement icon (context menu opens); Choose "Show XML" ("XML" box opens)


A 'quick and dirty' Effect placement XML example copied from ADE:

<SceneryObject
   lat="47.480906"
   lon="-123.118131"
   alt="0.0M"
   altitudeIsAgl="TRUE"
   pitch="0"
   bank="0"
   heading="0"
   imageComplexity="VERY_SPARSE">
   <NoCrash/>
   <NoFog/>
   <NoShadow/>
   <Effect
      effectName="effect_Ha code mmerfest_leadin_3.fx"
      effectParams=""/>
</SceneryObject>

NOTE: The above XML code Element gets inserted into other additional code in order to make a BGL



Effect placement XML example for a 'stand-alone BGL' when compiled by FSX SDK BGLComp

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Created by Scenery Design Engine (SDE) on 7/18/2013 -->
<FSData
   version="9.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="bglcomp.xsd">
   <SceneryObject
      lat="47.4809058755636"
      lon="-123.118131011724"
      alt="0.0M"
      altitudeIsAgl="TRUE"
      pitch="0"
      bank="0"
      heading="0"
      imageComplexity="VERY_SPARSE">
      <NoCrash/>
      <NoFog/>
      <NoShadow/>
      <Effect
         effectName="effect_Hammerfest_leadin_3.fx"/>
   </SceneryObject>
</FSData>

NOTE: The method immediately above allows you to insert BiasX (or other parameters) at a proper location within XML Element code via ex: NotePad.


BTW: I'm wondering if your prior efforts to achieve an offset may have been unsuccessful, because use of the "BiasX" parametric element in your XML placement code was still required, in spite of what 'offset' was requested in the *.FX code itself ?

Would you be so kind to check the stock fx_EmergencyLights.fx?
Just place it (on its own, not attached to an object) next to your threshold and see if there is a small distance between the two lights (as coded) or not.

fx_EmergencyLights.fx

There is a predominant pattern of 2 Red flashes followed by 2 (brighter) White flashes, but it does randomize slightly at times.


FYI: If you wish to more easily inspect rapidly sequenced Effects (ex: lights) you can:

1.) Set FS Time Of Day (aka "TOD") at dusk

2.) Set Simulation Rate at "Slowest"

For the time being I settled with a version that uses a controller which gives also a reliable sequencing and synchronization.

Congratulations on your new approach lighting !

I see that the 3 strobes are sequenced from NW to SE starting relative to the Finney Crosshairs Plus aircraft positioned at a 360 degree heading.


Keep up the nice work !

GaryGB

 

[abax2000]

BTW: I'm wondering if your prior efforts to achieve an offset may have been unsuccessful, because use of the "BiasX" parametric element in your XML placement code was still required, in spite of what 'offset' was requested in the *.FX code itself ?

A BIAS there would refer to the whole effect, and not to a specific emitter.

There is a predominant pattern of 2 Red flashes followed by 2 (brighter) White flashes, but it does randomize slightly at times.

The red flash "should" be spaced 1 meter apart from the white flash (continuously).
Thanks for trying out (at least helped my sanity check)

 

[GaryGB]

A BIAS there would refer to the whole effect, and not to a specific emitter.

Indeed; however, I assumed your ultimate goal might be:

* A longer "running rabbit" type sequence of multiple groups of Effect lights, each emitted from a preceding Effect ...with offsets.

* A brighter light system


NOTE: IIRC, Effects are more "dim" than ASM-coded 'BGL_Lights', thus must be placed multiple times to achieve brightness.


FYI: Achieving visibility of Effect lights at a distance, as well as visibility of Effect lights as a function of whether one has departed from the airport in question, or is inbound to the airport in question from a distant departure point:

http://www.fsdeveloper.com/forum/showthread.php?t=426678&highlight=visibility


Some have worked around this by "attaching" the Effect light to a 3D object which is itself invisible (un-textured), and the size of that 3D object is purposely set large enough to be visible at the desired distance from one's aircraft, when tested via trial and error relative to the default threshold for visibility of 3D objects in FS at run time, and/or as modified by an explicit FSX.Cfg parameter tweak (which still works in FSX SP2 Acceleration):

"SmallPartRejectRadius=0.0"


As an example, here's an excerpt from my own FSX.Cfg (with pertinent 'comments' by others which I keep right inside FSX.Cfg):

[SCENERY]
SmallPartRejectRadius=0.0
//
// SmallPartRejectRadius=<pixels>
// The default is 1.0 (i.e. 1 pixel). '2', and '4' are the next 2 settings we advise (but '4' or '5' can extend visibility to avoid Perf hit).
// This is a scenery tweak to eliminate very small objects, which can reduce render time.
// Basically this culls out small model parts (e.g. air conditioners on roofs of buildings, aircraft doors)
// if their radius would occupy less than the specified number of screen pixels.
// This can significantly improve performance but may cause “popping” of small objects
// NOTE: Ex: with '4' or '5', VRS Superbug disappears at 1/2 mile; with '0' or '1', you'll be able to see it for 5 miles
// (Depends on flight scenario conditions, zoom level, resolution etc. and... your eyesight)
// Beware... If graphics settings are high and you fly in large urban areas, this tweak needs a fast CPU and lots of memory
// Every detail, like air conditioner units on the roof tops will be painted by the graphics engine.
// NOTE: FSX re-started (after a full exit) very fast with 1.0 as value !"

BTW: I use "SmallPartRejectRadius=0.0" to maximize visibility at a distance, as IMHO, FS visibility appears closer to that of real life.


Sorry if I was mistaken as to your goal; I could not find the actual airport lighting specifications for Hammerfest after a (brief) search.

http://en.wikipedia.org/wiki/Approach_lighting_system


But, my presumption was based on the fact that Hammerfest reportedly has a 880-meter (2,890 ft) runway aligned 05–23:

http://en.wikipedia.org/wiki/Hammerfest_Airport


...And:

"The required minimum visibility for instrument approaches is influenced by the presence and type of approach lighting system. In the U.S., a CAT I ILS approach without approach lights will have a minimum required visibility of 3/4 mile, or 4000 foot runway visual range. With a 1400 foot or longer approach light system, the minimum potential visibility might be reduced to 1/2 mile (2400 runway visual range), and the presence of touchdown zone and centerline lights with a suitable approach light system might further reduce the visibility to 3/8 mile (1800 feet runway visual range)."

"In configurations that include sequenced flashing lights, the lights are typically strobes mounted in front of the runway on its extended centerline. These lights flash in sequence, usually at a speed of two consecutive sequences per second, beginning with the light most distant from the runway and ending at the Decision Bar. RAIL are similar to sequenced flashing lights, except that they end where the white approach light bars begin. Sequenced flashing lights and RAIL do not extend past the Decision Bar to avoid distracting the pilot during the critical phase of transitioning from instrument to visual flight.[3] Sequenced flashing lights are sometimes colloquially called the rabbit or the running rabbit."

http://en.wikipedia.org/wiki/Approach_lighting_system


If, however, I was correct in my interpretation of your intended lighting type, you may wish to also do a search here at FS Developer using the query string: "running rabbit" for info on how others have implemented such sequential lights without limited visibility issues.

The red flash "should" be spaced 1 meter apart from the white flash (continuously).

Although the stock "fx_EmergencyLights.fx" light splash from each light color is large, with monitor brightness turned down and FS Simulation Rate at "Slowest", I am unable to discern that their respective points of emission are even as much as 1 Meter apart ...along either axis of the Finney Cross Hairs Plus aircraft when facing a Heading of MAG 360.


Hope this helps !

GaryGB

 

[abax2000]

The approach lights at the airport I am revamping are not standard (very short).
Being illiterate on ASM\SCASM, I just settled with the shortest approach lighting that stock FSX can provide.
The sequenced lights are needed further away from the approach lights (IRL there are two groups of three sequenced lights at the extended CL).

So now I have them, using the controller solution which works exceptionally good.

Achieving visibility of Effect lights at a distance, as well as visibility of Effect lights as a function of whether one has departed from the airport in question, or is inbound to the airport in question from a distant departure point:

As for the non-appearing light when arriving see post no6 (just before EDIT).
I don't think that the visibility in distance is a problem with effects (at least for this use). The only downside is that the lights are unnaturally big when viewed from a very close distance (but again you never fly at 10m from the leadin lights - hopefully).

Some have worked around this by "attaching" the Effect light to a 3D object which is itself invisible (un-textured), and the size of that 3D object is purposely set large enough to be visible ...

I have not thought that the lights visibility can be influenced by the size of the object they can be attached on. I usually use poles that are themselves quite slim. Next time I will try this trick to see if it works.

...you may wish to also do a search here at FS Developer using the query string: "running rabbit" for info on how others have implemented such sequential lights without limited visibility issues....

Have done that, with no luck. Mostly ASM related (as said I have no idea of ASM) and animations (which anyhow must be at least as heavy as an effect).

* A longer "running rabbit" type sequence of multiple groups of Effect lights, each emitted from a preceding Effect ...with offsets.

That was my second attempt. Still I cannot find the way to make an effect to emit effects (at least in a useful way for this application). Even if this gets done, we are talking again for at least 2 effects working (so probably no benefit against the controller).
(anecdote)trying to get this done, for the time I have build rockets, chaff launchers, flares, bouncing light balls..you name it, except the intended outcome

...I am unable to discern that their respective points of emission are even as much as 1 Meter apart ...

What I see is the one on top of each other. Which is what you get even if you edit the effect and make the light ball smaller.
I found it hard to believe that a stock effect is not rendered as intended, and that is why I asked for your confirmation (4 eyes are always better )

 

[Deleted member 12505]

Sorry to bring this thread back from the dead ... as pointed out Emitter.x XYZ offsets don't seem to work with any type an are always bound to attachments. After checking 100's of .fx files and not finding a single file with any values other than 0 in XYZ offsets for Emitters, it would seem this is not implemented per everyone's conclusions.

But, to muddy these waters, setting Emitter XYZ velocity values adjusts the location of the Emitter ... specifically check out fx_SnowEngineWash.fx. I've brought this to LM's attention and one of the developers (Kevin) had indicated he fixed the issue in FX Tool with the latest v2.5 SDK. So I was testing out the fix and unfortunately it appears to be unchanged ... so I've reported my findings back to LM.

Seeing as this thread is old, if anyone has discovered any more recent info, please let me know.

Cheers, Rob.

 

[GaryGB]

Hi Rob, and thanks for that update.

I am presently unable to test this as I have not yet installed either version of P3D, but I'm curious whether, with your extensive experience with P3D, you may have also tested this in P3D v1.4 ?

Also, are you able to achieve a "desired and predictable" offset of Effect display via use of the FS "Visual Effects Tool" ...as described here ?

http://www.fsdeveloper.com/forum/threads/effect-altitude.428255/#post-686100

http://www.prepar3d.com/SDKv2/LearningCenter/modeling/creating_special_effects.html#The FX Tool Dialog



I believe there may be some ongoing and potentially increasing interest in use of the P3D v1.4 SDK as the drama unfolds about FSX_SE not having a "complete" FSX-compatible SDK distributed via STEAM for newcomers to the MSFS-ESP-P3D v1.4 platform, which potentially may prove to be a stepping-stone to P3D v2.x for many end users; thus having this fixed in the P3D v1.4 SDK as well may prove mutually-beneficial to both LM and the FS development Community in general.


[EDITED]

PS: There have been a number of inquiries and tentative conclusions regarding various factors associated with "offset" display of Effect (*.Fx) files in threads here at FSDeveloper which IMHO may merit consideration when troubleshooting this type of scenario in both FSX and P3D:

https://www.google.com/#q=fsdeveloper.com effect offset

One might wonder to what extent there may be some additional association with factors such as Drawcall batching and Tessellation which apparently affect display of scenery objects with ex: pitch and bank:

http://www.fsdeveloper.com/forum/threads/pitch-bank-not-applied-to-scenery-objetcs.431792/


...as well as being associated with offset of "wave" Effects and Ground Polygons:

http://www.fsdeveloper.com/forum/threads/ground-poly-shift.429902/page-3

http://www.prepar3d.com/forum-5/topic/ground-polygon-alignment-problem-when-tessellation-enabled/


...and offset as a result of object placement Altitude:

http://www.fsdeveloper.com/forum/threads/effect-altitude.428255/


Also, of incidental note is the report of "Shadow" offset:

http://www.fsdeveloper.com/forum/threads/my-curse-with-the-shadows-offset.425419/

[END_EDIT]


Thanks again for sharing your insights and potential benefits of your communications with LM with us here (and elsewhere) !

GaryGB

 

[L_Rob]

Hi Folks,
I hope I'm not going over something already hashed out, but I wanted to mention a tentative conclusion after playing around with effect offsets in order to position a rise and fall bow wave in P3D v2.5. Initially nothing made consistent sense, but I now have a hunch as follows and I'm wondering if it's consistent with what others have found.

The standard convention for effects is in terms of positive values for x, y z is right, up, forward, but the question is in relation to what? There are actually three potential frames of reference; the frame of the datum, the frame of the emitter and the frame of the particle. Sometimes they are all the same but not always. I think it works like this: the emitter frame is the same as that of the datum. For the datum of AI boats, +z is forward, and the emitter follows this convention. However based on what I've seen so far the frame of the particle is related to the heading of the emitter. Say you set the heading at 90 degrees so the effect will display parallel to the axis of the boat. Now the plus z axis for particle offsets is at 90 degrees to the axis of both the emitter and the boat, and to move the particle forward negative x values are needed. What this means in practice is that if you have a large lateral particle offset and change the heading value of the emitter, the effect will move way more than you might expect and in a way that's otherwise confusing. All this seems to be dependent on the particle type and the ground normal setting. Eg, type 25 particles (wakes) may not obey all of these conventions. Contrary to what I thought earlier, both emitter and particle offsets work in P3D v2.5 which is nice. Does this seem consistent with what others have found?

Edited to add:
I should add that the different x,y,z coordinate systems that get translated one to the other can really be confusing. Unless I read my little cheat sheet wrong, it seems to work like this if you use Sketchup: The convention in SU as well as MCX (in meters) is right, forward, up. When the model is compiled, the coordinate system as used in the sim.cfg (other than the camera definitions) and the sim.cfg changes to forward, right, up in feet. This is the coordinate system used by the datum to which the effect is attached. The coordinate system used within the effect itself becomes right, forward, up in meters with the exception that the scale, scale goal and scale rate have no z value.