Re: pfLightPoint bug?

New Message Reply Date view Thread view Subject view Author view

Simon Bennett (simonb++at++wormald.com.au)
Tue, 28 Feb 1995 12:28:31 +1100 (EST)


On Thu, 20 Oct 1994, Marcus wrote:

Does anybody know more about the subject below? I'm getting this sort of
behaviour... Specifically what I'm seeing is:

        * Crashing on pfGetLPointColor() calls with some database's
        * Other pfLightPoint nodes only have sigificant colours in the 0
          index of the node (I gather this is related to the PFGS_OVERALL
          colormode)

Does anybody know if:

        * The flight 14.1 loader always uses this PFGS_OVERALL color mode
          (listed in the pfPrint output)

        * PFGS_OVERALL is causing Performer to crash in the pfGetLPointColor
          calls?

        * The PFGS_OVERALL color mode for lightpoints is documented
          anywhere?

Also I remeber hearing about a limitation with Performer and flight
databases that doesn't allow you to draw a seamless bidirectional
lightpoint with different colour per side.... Can anybody confirm or
deny this?

Experiences anyone?

Thanx

<from a previous posting>
> >I have a question about pfLightPoints in Performer 1.2. The man page
> >says the individual points in the object share all attributes (e.g.
> >shape) except position and colour. However, this intriguing snippet
> >from pf.h suggests the possibility of a global binding for colour:
> >
> >/* pfLPointColor() */
> >#define PFLP_OVERALL -1
> >
> >Indeed, the a certain well-known 3D database file loader seems to
> >make this assumption, viz.:
> >
> > /* Set overall color if possible */
> > if(!colorDiff)
> > pfLPointColor(lp, PFLP_OVERALL, lc);
> >
> >Our experience with pfLightPoints created thus is that an attempt
> >to access individual colours dumps core:
> >
> > pfGetLPointColor((pfLightPoint), 0, (pfVec4));
> >Is the overall binding for the colour attribute valid and useful?
> >If so, how might one determine whether this binding applies to a
> >given pfLightPoint other than by a post-mortem on the resulting
> >core file?
> >
> >-----------------------------------------------------------------
> > | Jean Daigle ATS AeroTechnologies Inc. |
> > | Software Designer 1250 Boul Marie-Victorin |
> > | St. Bruno, QC J3V 6B8 |
> > | jaydee++at++ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 |
> >-----------------------------------------------------------------
>
> I was recently looking at the ASCII output of a scene graph that
> has lightpoints in it:
>
> [5:0]pfLightPoint pfId=8 0x82e800 {
> trav masks: cull=0xffffffff draw=0xffffffff isect=0xffffffff
> bsphere: ctr(-65.000000, -8.660254, -5.000000) rad=11.180340
> Num Points: 5, Size: 2.000000 FogScales: 2.000000 2.000000
> shape: dir=PFLP_OMNIDIRECTIONAL henv=179.000000 venv=179.000000
> falloff=4.000000
> Rot: azim=0.000000 elev=0.000000 roll=0.000000
> Color mode: PFGS_OVERALL, color: 0.109804 0.874510 0.168627 1.000000
> Point 263527468: -70.000000 -17.320507 -10.000000
> Point 263527468: -60.000000 -17.320507 -10.000000
> Point 263527468: -70.000000 -8.660254 -5.000000
> Point 263527468: -60.000000 -8.660254 -5.000000
> Point 263527468: -60.000000 0.000000 0.000000
> ^^^^^^^^^^^^^^^^
> [5:0]} pfLightPoint 8 0x82e800
>
> Notice that the RPointS numbers are outrageous. I would expect
> them to be 0, 1, 2, 3, and 4.
>
> Is this a bug in Performer 1.2?
> Is it why pfGetLPointColor() crashes as explained by Jean above?
>
> Regards,
> Marcus Barnes, Member Technical Staff
> MultiGen Inc., 1884 The Alameda, San Jose CA, 95126
> PH: (408) 261 4118 FX: (408) 247 4329
> EMAIL: multigen!marcus++at++uunet.UU.NET

+--------------------------------------------------------------------------------+
    Simon Bennett simonb++at++wormald.com.au
    Wormald Technology Advanced Systems Engineering Ph: +61 2 981 0611 (x512)

   Computer Terms: hardware - the part of a computer system that one can kick


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:00 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.