Posted by Frank C. on January 21, 2004 at 16:29:06:
On 21-Jan-04, at 6:33 PM, Joseph J. Strout wrote:> At 6:05 PM -0500 1/21/04, Frank C. wrote:
>
>>> Extensions to what? You're not proposing that we need new Quesa
>>> APIs for dealing with this, are you?
>>
>> Maybe I'm misunderstanding the whole 3DMF/QD3D philosophy but I
>> thought it was standard practice to add extensions to the format to
>> cater to specific renderers, and that those attributes are simply
>> ignored if a renderer doesn't support them.
>
> But it's Quesa philosophy to be binary compatible with QD3D.
> Extensions to enable the current (broken!) behavior would be fine, but
> by default, code that works with QD3D should work with Quesa.It shouldn't affect that aspect...
>> I'm suggesting that perhaps Quesa's default interactive renderer
>> could use some extensions to keep up with the times, (or in this case
>> keep up with QD3D) though I suppose it could just as easily be done
>> in a plug-in renderer.
>
> Hmm... I guess I'm still confused then. If you're talking about code
> within Quesa's IR, then these would be extensions to what, exactly?
> Our own IR doesn't need new Quesa APIs to change its behavior, so
> maybe you're talking about OpenGL extensions or some such?I mean extensions to 3DMF/Trimesh, that renderers can choose to ignore
or implement. From Apple's QD3D book's Preface:"Although QuickDraw 3D provides a large set of basic 3D objects and
operations, it is also designed for easy extensibility, so that you can
add custom capabilities (for instance, custom object types, attributes,
renderers, and shading algorithms) to those provided by QuickDraw 3D.">> The texture and fog are rendered at the same time, so the current
>> blend mode affects both. You could blend fog in a separate pass (and
>> many games do, especially for volumetric effects) but that would
>> incur a performance hit.
>
> Hmm. So you're saying, OpenGL simply doesn't have any way to say "do
> this with the textures" and "do that for the fog." It's just one
> setting, and it affects both. Yuck. Is there no way around that
> short of a separate rendering pass?GL fog is basically just a vertex colour so ya, you bind a texture and
render a vertex and it draws according to the current blend state.> I suppose then we might have to go with a separate pass for the fog.
It has certainly been done before...
> We already need multiple passes when translucent objects are involved,
> as I understand it.That's not technically a second pass - they're just drawn last, sorted
back to front...> Maybe one more won't slow things down too much.
A fog pass would have to draw the entire scene again, but it's not that
scary a thought since you don't have to worry about
textures/lighting/depth, and may be able to cache all the triangles
into one big array on the first pass. May be worth a shot...Frank.