Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

Quesa Wrappers questions (Real Studio games Mailinglist archive)

Back to the thread list
Next thread: RBGL started at SourceForge


Declare wrapper functions vs. straight declares -- performace   -   Asher Dunn
  Quesa Wrappers questions   -   Jeff Quan
    Re: Quesa Wrappers questions   -   Frank Condello
    Re: Quesa Wrappers questions   -   Jeff Quan
    Re: Quesa Wrappers questions   -   Frank Condello

Quesa Wrappers questions
Date: 31.03.05 03:06 (Wed, 30 Mar 2005 18:06:56 -0800)
From: Jeff Quan
I've finally sat down to play with Frank's Quesa Wrappers, attempting
to add attributes to Object3Ds loaded externally. What I came up with
was to create an OrderedDisplayGroup and add an AttributeSet to it,
setting things like transparency and specularity. I then add the loaded
object in with an AddObject Model..GetShapeHandle(0). This works for
objects with a single shape.

For the curious, the code looks something like this:

Dim DG as OrderedDisplayGroup3D
Dim Attr as AttributeSet3D
Dim Obj as Object3D

DG = new OrderedDisplayGroup3D
Attr = new AttribuetSet3D
Attr.TransparentColor = &c000000
DG.AddObject Attr
DG.AddObject Model.GetShapeHandle(0)
Obj.AddShapeFromDisplayGroup(DG) // Now treat it like any other
object3D.

My first question is this: is this a good way to add attributes, or can
one directly add and/or modify attributes to an externally-loaded
Object3D model?

My second question is how to do the above with a multi-shape model?

=Jeff Quan
<email address removed>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Quesa Wrappers questions
Date: 31.03.05 08:43 (Thu, 31 Mar 2005 02:43:12 -0500)
From: Frank Condello
On 30-Mar-05, at 9:06 PM, Jeff Quan wrote:

> I've finally sat down to play with Frank's Quesa Wrappers, attempting
> to add attributes to Object3Ds loaded externally. What I came up with
> was to create an OrderedDisplayGroup and add an AttributeSet to it,
> setting things like transparency and specularity. I then add the
> loaded object in with an AddObject Model..GetShapeHandle(0). This
> works for objects with a single shape.
>
> For the curious, the code looks something like this:
>
> Dim DG as OrderedDisplayGroup3D
> Dim Attr as AttributeSet3D
> Dim Obj as Object3D
>
> DG = new OrderedDisplayGroup3D
> Attr = new AttribuetSet3D
> Attr.TransparentColor = &c000000
> DG.AddObject Attr
> DG.AddObject Model.GetShapeHandle(0)
> Obj.AddShapeFromDisplayGroup(DG) // Now treat it like any other
> object3D.
>
> My first question is this: is this a good way to add attributes ...

That should work most of the time, but it's a bit of a round-about way
to do this.

> or can one directly add and/or modify attributes to an
> externally-loaded Object3D model?

Yup. The rough equivalent of your method above would be something like
this:

Dim dg As DisplayGroup3D
Dim mat as AttributeSet3D

dg = Model.GetFirstDisplayGroupInShape(0)
if dg <> Nil then
mat = New AttributeSet3D
mat.TransparentColor = &c000000
dg.MoveToFirstPosition
dg.AddObjectBefore(mat)
end if

That'll affect the "Model" Object3D directly, but neither of these
methods are 100% reliable since your attribute set can be overridden by
attributes further down the 3DMF hierarchy. If you're only using this
method on known models and it's working as expected, then you should be
fine, but in general you should work on the attribute set closest to
the drawable object. The attribute set attached to a trimesh is what
you'll want most of the time, but trimeshes can override colour
attributes with vertex attributes, so even that won't work 100% of the
time.

> My second question is how to do the above with a multi-shape model?

Just do it for each Shape with Model.GetFirstDisplayGroupInShape(n) or
some such in a loop.

Keep in mind that the wrappers provide you with a pointer to a Quesa
object wrapped up in a REALbasic class instance. You can apply the same
AttributeSet3D to a bunch of shapes, then keep that AttributeSet3D
around and change its properties at any time and all the shapes using
that set will update automagically. Shared objects are really cool in
that regard, but they also leave a lot of room for confusion if you
don't keep on top of things.

One more thing: You'll probably want to stick to grey tones for
transparency colours to get more predictable results. RGB is converted
to grey inside Quesa, but I'm not sure if it's based on luminance or
raw values.

HTH!
Frank.
------------
Open Source RB Plugins and Classes
<http://developer.chaoticbox.com>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Quesa Wrappers questions
Date: 31.03.05 17:38 (Thu, 31 Mar 2005 08:38:57 -0800)
From: Jeff Quan
On Mar 30, 2005, at 11:43 PM, Frank Condello wrote:
> Keep in mind that the wrappers provide you with a pointer to a Quesa
> object wrapped up in a REALbasic class instance. You can apply the
> same AttributeSet3D to a bunch of shapes, then keep that
> AttributeSet3D around and change its properties at any time and all
> the shapes using that set will update automagically. Shared objects
> are really cool in that regard, but they also leave a lot of room for
> confusion if you don't keep on top of things.

Thanks Frank, lots of good info. I'm just starting to get my bearings
on the inner workings of Quesa/QD3D.

> One more thing: You'll probably want to stick to grey tones for
> transparency colours to get more predictable results. RGB is converted
> to grey inside Quesa, but I'm not sure if it's based on luminance or
> raw values.

Yes, I'm already using grey. I actually haven't tried inputting
different values for each RGB channel, but I bet there's some neat
effects to be had by doing so.

I'm still running tests on how things affect transparency. What I've
found so far is this:
If you want to fade a model (with no alpha mask) out smoothly and it
has specularity, then fade out the SpecularColor as well or set it
initially to &c000000 (no specularity). If you don't do this fade, the
object's texture(s) will disappear but it's specularity will still
remain until transparency = &c000000, at which point the object will
disappear entirely and create a visual pop.

This one is slightly trickier: If you want to fade a masked sprite (ie:
AddShapePictureWithMask), then fade out its DiffuseColor as well. If
this is not done, then it seems as if the sprite's mask is faded out,
but the texture remains at 100% until transparency = &c000000 (another
visual pop). Fading the diffuse color is akin to fading the texture to
black and due to alpha blending will look like the sprite is
disappearing. While I haven't tested this, I'm assuming this works
similarly for models with alpha masks.

Oh, and transparency is one case where the number of polygons does
matter. Fading out 30 models is much slower than fading out 30 sprites.
Makes sense, as transparency is a more render-intensive operation.

Bottom line is that there's a lot that can be done just by messing with
transparency, specular, and diffuse channels.

=Jeff Quan
<email address removed>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Quesa Wrappers questions
Date: 31.03.05 20:34 (Thu, 31 Mar 2005 14:34:41 -0500)
From: Frank Condello
On 31-Mar-05, at 11:38 AM, Jeff Quan wrote:

> If you want to fade a model (with no alpha mask) out smoothly and it
> has specularity, then fade out the SpecularColor as well or set it
> initially to &c000000 (no specularity). If you don't do this fade, the
> object's texture(s) will disappear but it's specularity will still
> remain until transparency = &c000000, at which point the object will
> disappear entirely and create a visual pop.

Good point. Rendering a strong highlight on a barely visible object is
actually a neat effect though (poor man's Fresnel reflection).

> This one is slightly trickier: If you want to fade a masked sprite
> (ie: AddShapePictureWithMask), then fade out its DiffuseColor as well.
> If this is not done, then it seems as if the sprite's mask is faded
> out, but the texture remains at 100% until transparency = &c000000
> (another visual pop).

Another good point. This kinda blows, as it's unintuitive and won't
work on lit geometry - more below...

> Fading the diffuse color is akin to fading the texture to black and
> due to alpha blending will look like the sprite is disappearing. While
> I haven't tested this, I'm assuming this works similarly for models
> with alpha masks.

It should work the same way for models, but only null shaded (unlit)
textured objects will actually blend diffuse colours, so although this
won't be a problem for the majority of sprites, it will be a problem
for most meshes. This could be considered a Quesa bug however,
especially if it's handled properly in QD3D (which I'd expect it would
be, since QD3D doesn't suffer from related additive problems that
premultiplied alphas expose in OpenGL). It should be easy enough for
Quesa to fade the diffuse colour automatically for the lit cases. The
null shaded cases are a bit tricker, since you need to take any user
defined colours into account, but it should still be doable.

I actually use a hacked Quesa library to enable diffuse blending on lit
objects at all times. Although the QD3D behaviour seems logical from a
programmer's perspective, it makes little sense to me from an artistic
point of view. When I gave the blending code in Quesa an overhaul last
year the folks on the Quesa list insisted the QD3D behaviour be
maintained, so there it is. I may eventually set this up as a global
runtime switch via Quesa's SetProperty API, so maybe it'll make it into
the official release at some point.

> Oh, and transparency is one case where the number of polygons does
> matter. Fading out 30 models is much slower than fading out 30
> sprites. Makes sense, as transparency is a more render-intensive
> operation.

Yes, very much so. Alpha blending can strain the GPU somewhat but the
main slowdown is due to the fact that all transparent triangles are
lumped together and manually sorted back to front, which is an
exponentially expensive process. This is one area where a custom engine
can be tweaked for much faster results, but Quesa has to assume the
worst case all the time and use a generic (i.e. slow) algorithm to
ensure correct results.

Frank.
------------
Open Source RB Plugins and Classes
<http://developer.chaoticbox.com>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>