realbasic-games
[Top] [All Lists]

Re: Text3D Class (beta) for RB3D

To: REALbasic Games <realbasic-games at lists dot realsoftware dot com>
Subject: Re: Text3D Class (beta) for RB3D
From: Lo Saeteurn <realbasic at miensoftware dot com>
Date: Wed, 29 Mar 2006 13:14:07 -0800
Delivered-to: realbasic-games at lists dot realsoftware dot com
References: <D3680394-40D3-406E-92B9-DE40DCBB62E0 at miensoftware dot com> <a0620073bc050576daca9 at [10 dot 0 dot 1 dot 2]> <252A1B36-40F5-4F9B-9985-E048B1A1FC72 at miensoftware dot com> <a06200742c050640ea26f at [10 dot 0 dot 1 dot 2]>
Hmm... that's an interesting point. You can duplicate a TriMesh and share the texture data, which is the vast majority of it (I assume each character is just 4 vertices and 2 triangles, right?), but you can't share the vertex and triangle data itself.

Isn't this slower than cloning an object3D?

Thinking out loud here...  So each character is a separate object?

Yep, each character is an object3D registered into the Text3DManager.

Even when they're clones, I would think that this might bog the system down a bit if you have lots of characters on screen. I wonder if it'd be better to have a single Trimesh for each "block" of text (where a block could be the whole screen, or could be just a rectangular area on one portion of the screen), and then have 4 vertices + 2 triangles for each character to display. Attached to this TriMesh would be a single texture containing all the character images. To change the text, you'd simply change the UV coordiantes of the corresponding 4 vertices.

The advantage of this approach, in terms of speed, is that there's only one object. Yes, it'd have a lot of triangnles, but no more than the separate-objects approach. And Rb3D tends to be much more efficient when handling a single object with lots of triangles, than when handling many objects. It also means that you can change the text pretty much instantly; no need to clone anything or move any objects around.

The disadvantage, I suppose, is that reorganizing your Trimesh every time to optimize it for the number (and position) of characters actually displayed would be a PITA to code. But you might just keep all the triangles for every character present all the time (I'm assuming a monospaced display, like a Terminal window), and just flip the unused spaces around or point them at a transparent part of the texture or some such.

Well this could be done, but it is a bit more complicated. This would only work with fixed widths. I'm currently using variable widths. This approach pretty much has to recreate the trimesh each time there are changes, but we could just update the vertex positions (as you suggested) and flip the windings for all excess characters. What about resizing? Wouldn't I need to create a new trimesh for this? How fast could all this be achieved? For my current approach, I can dynamically change an approximate 27-character text 1,000 times (with variable widths and variable character count) within a period of 2 seconds on my 800mhz iBook--rendering speed is another story.

I do know how slow Quesa processes several individual objects as opposed to everything in one trimesh. This is why I added the combine- object-by-texture feature in the RB3D Utility. This could be something I may want to look into if it really does affect rendering speed significantly with the amount of text I have on screen.

_______________________________________________
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>


<Prev in Thread] Current Thread [Next in Thread>