quesa-develop

More wireframe renderer

[Stefan H. <st...@to...>]

There are (at least for me) two missing wireframe renderer features:

1. Backfacing hide
2. Highlighting

It seems that the corresponding Quesa Interactive implementation can 
be (more or less) be reused.

   Stefan
   http://www.topoi.ch

Re: More wireframe renderer

[Jose' C. <cru...@ce...>]

Il giorno 11/apr/07, alle ore 23:05, Stefan Huber ha scritto:

> There are (at least for me) two missing wireframe renderer features:
>
> 1. Backfacing hide
> 2. Highlighting
>
> It seems that the corresponding Quesa Interactive implementation can
> be (more or less) be reused.
>
>    Stefan
>    http://www.topoi.ch

I've currently a person exploring new visualizations with multipass =20
rendering

(contours, hidden-line, flat shading ecc)

We're doing it modifying the new OpenGL renderer, once finished, we =20
have to talk about the best way to deploy, the current one will be =20
slowed by one test for a property at every pass, the multipass can be =20=

just added to the renderer, instead of create a new one...


in other news, The 3ds writer is growing slowly, I've submitted =20
several fixes to the Quessa library that prevent the new writer to work


Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Re: More wireframe renderer

[James W. <ja...@fr...>]

Jose' Cruanyes wrote:

> I've currently a person exploring new visualizations with multipass  
> rendering
> 
> (contours, hidden-line, flat shading ecc)
> 
> We're doing it modifying the new OpenGL renderer, once finished, we  
> have to talk about the best way to deploy, the current one will be  
> slowed by one test for a property at every pass, the multipass can be  
> just added to the renderer, instead of create a new one...

Is that going to be compatible with the current use of multiple passes 
to handle more than 8 lights?

Of course, one can also do multi-pass tricks in client code, since one 
can control whether Quesa clears buffers at the start of a frame, and 
whether Quesa swaps buffers at the end of a frame.

I wouldn't expect one property test per pass to be significantly slow. 
I'm planning to add a property test to determine whether to do per-pixel 
lighting.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Bug caused by emissive colour?

[Roger H. <rog...@mi...>]

I have spent the last three days tracing a problem with our  
application, that it will not print on PowerPC, even though it works  
fine on Intel.

It took me a day just to find between which two SVN revisions it went  
wrong.

The only thing that was changed between the last working revision and  
the first non working revision was that we imported many of the  
recent changes to Quesa.

Well, maybe we made a mess of selecting the changes we wanted, but I  
think it is worth warning you in case anyone else (a) is having a  
similar problem or (b) could throw some light on what is happening.


I used a binary sort on the changes, though the 'order' used for  
comparison  may not have been very scientific. Anyway, I identified  
the point it went wrong. It was when the emissive colour attribute  
was introduced into the TQ3ViewStackItem struct, and also into the  
constructor. It makes no sense that it should make it fail,  
especially only on one platform, and on printing only whilst working  
perfectly on screen. On OS9 I would might have suspected the stack  
was growing past its limit, but I don't think can easily happen on OS- 
X, and anyway, I think these are heap items merely pointed to by the  
stack.

For now I will remove the offending item (and everything which  
references it) from my latest code and see if that cures everything  
for me.

I'll let the list know how I get on.

Roger Holmes.

Re: Bug caused by emissive colour?

[Roger H. <rog...@mi...>]

>
> For now I will remove the offending item (and everything which
> references it) from my latest code and see if that cures everything
> for me.
>
> I'll let the list know how I get on.

It fixes the problem for me.

One minor bug and it  will probably be ready for issuing.

Roger.

Re: Bug caused by emissive colour?

[James W. W. <os...@jw...>]

On Apr 12, 2007, at 10:51 AM, Roger Holmes wrote:

>> I have spent the last three days tracing a problem with our
>> application, that it will not print on PowerPC, even though it works
>> fine on Intel.
>> ...

>> For now I will remove the offending item (and everything which
>> references it) from my latest code and see if that cures everything
>> for me.
>>
>> I'll let the list know how I get on.
>
> It fixes the problem for me.
>
> One minor bug and it  will probably be ready for issuing.

I looked through all the code that involves emissive color, and I  
can't find anything suspicious.  I also tried making Geom Test draw  
something with emissive color, and running it under Guard Malloc, on  
a PowerPC machine, and no problems showed up.

What exactly does "will not print" mean?  Did it crash, or spit out a  
blank piece of paper, or what?

Re: Bug caused by emissive colour?

[James W. W. <os...@jw...>]

On Apr 14, 2007, at 4:11 PM, James W. Walker wrote:

> What exactly does "will not print" mean?  Did it crash, or spit out a
> blank piece of paper, or what?

Another thought: when you print, I suppose you are using a bitmap  
draw context, yes?  Apple's OpenGL software renderer is a newer  
version on Intel than on PowerPC, not just a recompiled version of  
the same thing, so it's conceivable that you ran into a bug in the  
Apple software renderer.

Re: Bug caused by emissive colour?

[Roger H. <rog...@mi...>]

On 15 Apr, 2007, at 00:31, James W. Walker wrote:

>
> On Apr 14, 2007, at 4:11 PM, James W. Walker wrote:
>
>> What exactly does "will not print" mean?  Did it crash, or spit out a
>> blank piece of paper, or what?
>
> Another thought: when you print, I suppose you are using a bitmap
> draw context, yes?

Yes, though the draw contexts are a bit different on Cocoa, but I think
the bitmap ones are the same as the Carbon ones, its only the on
screen one that are different. I will look into this, I need to look  
at it
anyway before I ask you to check in the Microspot changes for it,
and I had better be sure I don't give you some rubbish code to
check in.

>   Apple's OpenGL software renderer is a newer
> version on Intel than on PowerPC, not just a recompiled version of
> the same thing, so it's conceivable that you ran into a bug in the
> Apple software renderer.

Could be.

Re: Bug caused by emissive colour?

[James W. <ja...@fr...>]

Roger Holmes wrote:

>> On Apr 14, 2007, at 4:11 PM, James W. Walker wrote:
>> Another thought: when you print, I suppose you are using a bitmap
>> draw context, yes?
> 
> Yes, though the draw contexts are a bit different on Cocoa, but I think
> the bitmap ones are the same as the Carbon ones, its only the on
> screen one that are different.

Let me know when you figure it out, because I don't understand how it 
can work on Cocoa.  When QUESA_OS_COCOA is true, GLDrawContext_New calls 
gldrawcontext_cocoa_new instead of gldrawcontext_mac_new.  But 
gldrawcontext_cocoa_new only handles kQ3DrawContextTypeCocoa, not 
kQ3DrawContextTypePixmap.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Bug caused by emissive colour?

[Roger H. <rog...@mi...>]

On 15 Apr, 2007, at 00:11, James W. Walker wrote:

>
> On Apr 12, 2007, at 10:51 AM, Roger Holmes wrote:
>
>>> I have spent the last three days tracing a problem with our
>>> application, that it will not print on PowerPC, even though it works
>>> fine on Intel.
>>> ...
>
>>> For now I will remove the offending item (and everything which
>>> references it) from my latest code and see if that cures everything
>>> for me.
>>>
>>> I'll let the list know how I get on.
>>
>> It fixes the problem for me.
>>
>> One minor bug and it  will probably be ready for issuing.
>
> I looked through all the code that involves emissive color, and I
> can't find anything suspicious.

Thank you.


>   I also tried making Geom Test draw
> something with emissive color, and running it under Guard Malloc, on
> a PowerPC machine, and no problems showed up.

Its not using emissive colour thats the problem, its something to do  
with
having the emissive colour field in the TQ3ViewStackItem record.


>
> What exactly does "will not print" mean?  Did it crash, or spit out a
> blank piece of paper, or what?

It prints a blank piece of paper, or a blank preview.

Re: Bug caused by emissive colour?

[James W. <ja...@fr...>]

Roger Holmes wrote:
> On 15 Apr, 2007, at 00:11, James W. Walker wrote:
>> What exactly does "will not print" mean?  Did it crash, or spit out a
>> blank piece of paper, or what?
> 
> It prints a blank piece of paper, or a blank preview.

Have you tried it under OpenGL Profiler with "Break on Error" checked?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: More wireframe renderer

[James W. <ja...@fr...>]

Stefan Huber wrote:
> There are (at least for me) two missing wireframe renderer features:
> 
> 1. Backfacing hide

Why do you think this is missing?  I definitely see the difference when 
I select Backfacing Style Remove in wireframe mode in Geom Test.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: More wireframe renderer

[Stefan H. <st...@to...>]

The behaviour between renderers and (fill) styles is not consistent.

Quesa Interactive renderer supports TQ3FillStyle:: kQ3FillStyleEdges 
in combination with TQ3BackfacingStyle:: kQ3BackfacingStyleRemove. 
That is what you have probably seen in Geom Test.

Quesa Wireframe renderer does not support the above combination. 
Actually Quesa Wireframe should ignore TQ3FillStyle (at least 
kQ3FillStyleFilled). Quesa Wireframe + kQ3BackfacingStyleRemove 
(ignoring kQ3FillStyleFilled ) should have (more or less) the same 
(redundant) effect as Quesa Interactive + kQ3FillStyleEdges + 
kQ3BackfacingStyleRemove.

Under QD3D there was a slight difference. QD3D Interactive + 
kQ3FillStyleEdges + kQ3BackfacingStyleRemove showed triangle edges 
(exception: high level geometries like cube). QD3D Wireframe showed 
surface edges.

By the way, Quesa OpenGL renderer does not support kQ3FillStyleEdges 
in combination with kQ3BackfacingStyleRemove.

   Stefan
   http://www.topoi.ch


>Stefan Huber wrote:
>>  There are (at least for me) two missing wireframe renderer features:
>>
>>  1. Backfacing hide
>
>Why do you think this is missing?  I definitely see the difference when
>I select Backfacing Style Remove in wireframe mode in Geom Test.
>--
>    James W. Walker, Innoventive Software LLC
>    <http://www.frameforge3d.com/>

Re: More wireframe renderer

[James W. W. <os...@jw...>]

On Apr 19, 2007, at 10:05 PM, Stefan Huber wrote:

> The behaviour between renderers and (fill) styles is not consistent.
>
> Quesa Interactive renderer supports TQ3FillStyle:: kQ3FillStyleEdges
> in combination with TQ3BackfacingStyle:: kQ3BackfacingStyleRemove.
> That is what you have probably seen in Geom Test.

No, I specifically looked at the wireframe renderer.

> Quesa Wireframe renderer does not support the above combination.

Yes it does....

> Actually Quesa Wireframe should ignore TQ3FillStyle (at least
> kQ3FillStyleFilled). Quesa Wireframe + kQ3BackfacingStyleRemove
> (ignoring kQ3FillStyleFilled ) should have (more or less) the same
> (redundant) effect as Quesa Interactive + kQ3FillStyleEdges +
> kQ3BackfacingStyleRemove.

And it does.

> Under QD3D there was a slight difference. QD3D Interactive +
> kQ3FillStyleEdges + kQ3BackfacingStyleRemove showed triangle edges
> (exception: high level geometries like cube). QD3D Wireframe showed
> surface edges.

I don't know what you mean by surface edges.

> By the way, Quesa OpenGL renderer does not support kQ3FillStyleEdges
> in combination with kQ3BackfacingStyleRemove.

Sorry to keep contradicting you, but yes, it does, I just tried  
that.  In fact, if you use the OpenGL renderer, kQ3FillStyleEdges,  
kQ3BackfacingStyleRemove, and kQ3IlluminationTypeNULL, it looks the  
same as the wireframe renderer with kQ3BackfacingStyleRemove.

Re: More wireframe renderer

[Stefan H. <st...@to...>]

You have right. Partly (sorry for not testing the issue thoroughly). 
For most geometries Wireframe backface culling works. But at least 
not for Cube, Mesh, Trimesh, and Polyhedron. With these geometries 
the Interactive renderer does his own culling (probably in 
IRGeometry_Generate_Triangle_Flags).

   Stefan
   http://www.topoi.ch


>On Apr 19, 2007, at 10:05 PM, Stefan Huber wrote:
>
>>  The behaviour between renderers and (fill) styles is not consistent.
>>
>>  Quesa Interactive renderer supports TQ3FillStyle:: kQ3FillStyleEdges
>>  in combination with TQ3BackfacingStyle:: kQ3BackfacingStyleRemove.
>>  That is what you have probably seen in Geom Test.
>
>No, I specifically looked at the wireframe renderer.
>
>  > Quesa Wireframe renderer does not support the above combination.
>
>Yes it does....
>
>>  Actually Quesa Wireframe should ignore TQ3FillStyle (at least
>>  kQ3FillStyleFilled). Quesa Wireframe + kQ3BackfacingStyleRemove
>>  (ignoring kQ3FillStyleFilled ) should have (more or less) the same
>>  (redundant) effect as Quesa Interactive + kQ3FillStyleEdges +
>>  kQ3BackfacingStyleRemove.
>
>And it does.
>
>>  Under QD3D there was a slight difference. QD3D Interactive +
>>  kQ3FillStyleEdges + kQ3BackfacingStyleRemove showed triangle edges
>>  (exception: high level geometries like cube). QD3D Wireframe showed
>>  surface edges.
>
>I don't know what you mean by surface edges.
not decomposed into triangles
>
>>  By the way, Quesa OpenGL renderer does not support kQ3FillStyleEdges
>>  in combination with kQ3BackfacingStyleRemove.
>
>Sorry to keep contradicting you, but yes, it does, I just tried 
>that.  In fact, if you use the OpenGL renderer, kQ3FillStyleEdges, 
>kQ3BackfacingStyleRemove, and kQ3IlluminationTypeNULL, it looks the
>same as the wireframe renderer with kQ3BackfacingStyleRemove.

Re: More wireframe renderer

[James W. <ja...@fr...>]

Stefan Huber wrote:

> You have right. Partly (sorry for not testing the issue thoroughly). 
> For most geometries Wireframe backface culling works. But at least 
> not for Cube, Mesh, Trimesh, and Polyhedron. With these geometries 
> the Interactive renderer does his own culling (probably in 
> IRGeometry_Generate_Triangle_Flags).

I think I finally understand what you're talking about.  If a TriMesh 
does not specify explicit edges (like the TriMeshes in the Quesa logo) 
then backfaces can be culled.  But if a TriMesh does specify explicit 
edges, then the Wireframe and OpenGL renderers simply draw each edge as 
a line, with no culling.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>