Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

On screen console (Real Studio games Mailinglist archive)

Back to the thread list
Next thread: Shiny!


[ANN] Preview of RBD 2.4   -   Marc Zeedar
  On screen console   -   Joseph Nastasi
   Re: On screen console   -   Joseph J. Strout
   Re: On screen console   -   Joseph Nastasi
   Re: On screen console   -   Frank Condello
   Re: On screen console   -   Joseph J. Strout
   Re: On screen console   -   Frank Condello

On screen console
Date: 13.01.06 20:48 (Fri, 13 Jan 2006 14:48:38 -0500)
From: Joseph Nastasi
I'd like some pointers on how to implement a generic text type display
that floats over a 3D scene. I got some ideas from Franks cool overlay
demo, but I'm wondering what's the best way to handle text that will
change on the fly. Looking to display real time flight data.

Thanks for any pointers or guiding beacons of hope....
:-)

Re: On screen console
Date: 13.01.06 21:16 (Fri, 13 Jan 2006 13:16:26 -0700)
From: Joseph J. Strout
At 2:48 PM -0500 1/13/06, Joseph Nastasi wrote:

>I'd like some pointers on how to implement a generic text type
>display that floats over a 3D scene. I got some ideas from Franks
>cool overlay demo, but I'm wondering what's the best way to handle
>text that will change on the fly. Looking to display real time
>flight data.

That's an interesting problem. With the new Material and Texture
classes, you could replace the texture of your console object (which
could be created with AddShapeFromPicture as an easy way to build it
in code) on the fly. But converting every pixel of a large picture,
on every frame of the animation, is likely to be a performance drag.

I think this is one of those cases (all too common in 3D game
development!) where, to get good performance, you need to examine
what additional constraints you have on the problem. Surely it's not
the case that the pixels in frame N+1 are mostly unrelated to the
pixels in frame N. So what's the behavior? If new data is going to
appear on bottom, with the previous data just scrolling up like in a
Terminal window, then one solution comes to mind. If the data is
going to consist of a bunch of stationary labels with changing
values, then a different solution is called for.

So, maybe if you describe more how it should look, we can all
brainstorm some good approaches.

Best,
- Joe

Re: On screen console
Date: 13.01.06 22:13 (Fri, 13 Jan 2006 16:13:11 -0500)
From: Joseph Nastasi

On Jan 13, 2006, at 3:16 PM, Joseph J. Strout wrote:
> That's an interesting problem. With the new Material and Texture
> classes, you could replace the texture of your console object (which
> could be created with AddShapeFromPicture as an easy way to build it
> in code) on the fly. But converting every pixel of a large picture,
> on every frame of the animation, is likely to be a performance drag.

I was thinking of that: drawing on a graphics object:
Graphics.DrawString and then it gets swapped for the current texture.

> I think this is one of those cases (all too common in 3D game
> development!) where, to get good performance, you need to examine what
> additional constraints you have on the problem.

I should have been clearer... It will probably be an overlay that has a
set of properties listed in a label: value pair. The actual number of
properties can change, but not in real time; they would be selected in
a window at another time.

> So, maybe if you describe more how it should look, we can all
> brainstorm some good approaches.

Similar to this:

http://pyramiddesign.us/aok/images/console.jpg

which is from an older version of X-Plane.

Thanks
Joe

Re: On screen console
Date: 13.01.06 23:02 (Fri, 13 Jan 2006 17:02:47 -0500)
From: Frank Condello
On 13-Jan-06, at 2:48 PM, Joseph Nastasi wrote:

> I'd like some pointers on how to implement a generic text type
> display that floats over a 3D scene. I got some ideas from Franks
> cool overlay demo, but I'm wondering what's the best way to handle
> text that will change on the fly. Looking to display real time
> flight data.

One major reason I dropped Quesa is the lack of a true orthographic/
overlay mode. My Rb3D overlay demo does some fancy math to achieve
something that really should be a lot simpler (and not such a burden
on the CPU). It also suffers from the fact that the "overlays" are
actually 3D objects, and will be clipped by "real" 3D geometry if
you're not careful. This was (AFAIK) the only way to achieve this
affect with QD3D, but Quesa introduced a rasterize camera transform
API and also exposes the depth buffer in ways that allow more proper
overlays to be implemented.

Taking advantage of these new Quesa APIs in Rb3D means overloading
the Rb3DSpace.Update method and creating your own submit loop - I've
done this, as part of an Rb3DSpaceEx subclass which also contains an
Overlays "array" that works like the built-in Objects property. I
also have several Overlay classes and BitmapFont3D/BitmapText3D
classes that integrate with overlays to print fixed-width strings
efficiently (i.e. not creating and uploading a new texture every
frame). This was all coded within my Quesa Wrappers framework as it
requires a lot of support code, and mostly works, but a Quesa bug
prevents picking from working with objects that go through the
rasterize transform matrix (show stopper #1), and Quesa's monolithic
transparency sorter makes overlays pathetically slow (show stopper
#2). So, this stuff remains unreleased.

In the end I got sick and tired of all these Quesa hacks and wrote my
own OpenGL renderer from scratch. I'm *much* happier now - coding 3D
in RB no longer feels like a wrestling a hippo (in the mud) and image
quality doesn't suffer from the limitations of an API written before
GPUs existed.

Sorry if this isn't helpful, but there ya go!

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.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: On screen console
Date: 13.01.06 23:20 (Fri, 13 Jan 2006 15:20:24 -0700)
From: Joseph J. Strout
At 4:13 PM -0500 1/13/06, Joseph Nastasi wrote:

>I should have been clearer... It will probably be an overlay that
>has a set of properties listed in a label: value pair. The actual
>number of properties can change, but not in real time; they would be
>selected in a window at another time.

OK, then let's see... it seems to be mostly a numeric display, so one
option would be to create a TriMesh that has a separate little pair
of triangles for each digit to be shown. Attach to this a texture
that has all ten digits in a strip. Then, at runtime, you can show
any digit in any position by just setting the UV coordinates of the
appropriate triangles. This is a bit of work to code, but it would
be blazing fast because you're not changing the texture (image) at
all, and yet the whole display (or at least, the changing parts) is
still one object.

A somewhat poorer approach would be to make a separate Object3D for
each digit, which means you could simply add the ten digits with
AddShapePicture and switch what is shown by assigning to the Shape
property. But you're likely to have trouble getting them to all line
up seamlessly next to each other.

HTH,
- Joe

Re: On screen console
Date: 13.01.06 23:46 (Fri, 13 Jan 2006 17:46:40 -0500)
From: Frank Condello
On 13-Jan-06, at 5:20 PM, Joseph J. Strout wrote:

> At 4:13 PM -0500 1/13/06, Joseph Nastasi wrote:
>
>> I should have been clearer... It will probably be an overlay that
>> has a set of properties listed in a label: value pair. The actual
>> number of properties can change, but not in real time; they would
>> be selected in a window at another time.
>
> OK, then let's see... it seems to be mostly a numeric display, so
> one option would be to create a TriMesh that has a separate little
> pair of triangles for each digit to be shown. Attach to this a
> texture that has all ten digits in a strip. Then, at runtime, you
> can show any digit in any position by just setting the UV
> coordinates of the appropriate triangles. This is a bit of work to
> code, but it would be blazing fast because you're not changing the
> texture (image) at all, and yet the whole display (or at least, the
> changing parts) is still one object.

I have code that does exactly this, but it's built on top of the
Quesa Wrappers. It shouldn't be *too* difficult to port it to use the
built-in Trimesh/Material however. If anyone wants this please
contact me off list, but note that it uses fixed-width glyphs and
only supports the standard ASCII character set (1-127).

It's also not as "blazing fast" as you might expect because bitmap
fonts tend to require alpha channels, and that means the mesh is
sorted and drawn triangle-by-triangle inside Quesa. A few lines is
ok, a whole page is so-so. Updating the trimesh can also be a
bottleneck due to all the accessor methods required to hack at UVs/
verts one at a time.

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.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>