quesa-develop — Mailing list for Quesa development

Per-pixel lighting now checked in

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

I've checked in my changes for per-pixel lighting.  There is a new 
source file, so projects and makefiles must be updated.  I updated the 
Xcode and CodeWarrior XML projects.

The difference between per-pixel lighting and per-vertex lighting is 
particularly noticeable when you use spotlights or nearby point lights. 
  I posted a sample under "Screenshots" in the Quesa area at SourceForge.

You get per-pixel lighting by selecting the OpenGL renderer and setting 
a property on the renderer object.  Geom Test now has a toggle for this. 
  If the OpenGL implementation (i.e., video card or software renderer) 
does not support OpenGL Shading Language, then the OpenGL renderer 
silently reverts to per-vertex lighting.

Per-pixel lighting does not yet support fog.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

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.

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: 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/>

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

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: Wireframe renderer problems

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

On Mar 31, 2007, at 12:36 PM, Stefan Huber wrote:

> 1. The wireframe renderer draws the triangle contours of a box but it
> should draw the rectangle contours. This can be solved by three lines
> of code (see below).

Done.

> 2. Diffuse colors which are part of the geometry will be drawn.
> Geometry independent attributes will be ignored. I think we should
> add a attribute state handler to the wireframe renderer to handle
> diffuse colors correctly.

Done.

Wireframe renderer problems

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

1. The wireframe renderer draws the triangle contours of a box but it 
should draw the rectangle contours. This can be solved by three lines 
of code (see below).

2. Diffuse colors which are part of the geometry will be drawn. 
Geometry independent attributes will be ignored. I think we should 
add a attribute state handler to the wireframe renderer to handle 
diffuse colors correctly.

   Stefan
   http://www.topoi.ch

________________________________________________
E3GeometryBox.c -> e3geom_box_create_face

TQ3TriMeshEdgeData	 edges[4] = { {{ 0, 1}, { 0, 
kQ3ArrayIndexNULL}}, {{ 1, 2}, { 0, kQ3ArrayIndexNULL}},{{ 2, 3}, { 
1, kQ3ArrayIndexNULL}},{{ 3, 0}, { 1, kQ3ArrayIndexNULL}} };

// Set up the TriMesh structure
...
theTriMeshData.numEdges = 4;
theTriMeshData.edges  = edges;

Lots of lights

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

I've updated the OpenGL renderer to be able to handle more non-ambient 
lights than OpenGL natively supports (which is usually 8), using 
multiple passes.  Naturally, this requires that you write a real 
rendering loop, checking the result of Q3View_EndRendering, as has 
always been recommended.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Per-pixel lighting

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

On 30 Mar, 2007, at 07:30, Jose' Cruanyes wrote:

>
>> Since the per-pixel lighting would still be pretty much renderer-
>> specific, using the ViewHints makes some sense to
>
> but ViewHints is a way to store renderer specific properties in a
> 3dmf file, so you both are saying the same thing
>

Yes thats right, they are intended just for use in files, though they  
can also be used to encapsulate the setup for one view to apply to  
another view.

Renderers can have a user interface. This is currently only used for  
plugin renderers but I don't think there is a restriction to them  
only. The Microspot renderer uses it though many of the calls it  
currently uses have been deprecated by Apple. The application just  
asks the renderer to interact with the user and so it has to have  
platform specific code to bring up a dialog or whatever and store the  
selected preferences in its own prefs file.

If it simply an on or off preference, then you could have one  
renderer with it on an another with it off.

Roger.

Re: Per-pixel lighting

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

Il giorno 30/mar/07, alle ore 02:58, Dan Zinngrabe ha scritto:

> Since the per-pixel lighting would still be pretty much renderer- 
> specific, using the ViewHints makes some sense to

but ViewHints is a way to store renderer specific properties in a  
3dmf file, so you both are saying the same thing


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Per-pixel lighting

[Dan Z. <que...@ma...>]

On Mar 29, 2007, at 5:42 PM, James Walker wrote:

> Dan Zinngrabe wrote:
>
>> 1. Style?
>> 2. View Hint (this is how it was traditionally done with plug-in
>> renderers in QD3D)
>
> It's my understanding that a view hints object is basically a way of
> wrapping up, for 3DMF storage, information that would exist  
> elsewhere at
> run time.  For example a view hint can record the clear image  
> color, but
> at run time the draw context object knows the clear image color.
>
> I'm leaning toward an object property on the renderer.  I don't  
> envision
> a great need to use it for some objects and not others.
> -- 
>    James W. Walker, Innoventive Software LLC
>    <http://www.frameforge3d.com/>
>


It's something that was renderer-specific back in the QD3D days. A  
good example would be material properties for one of the LightWork  
renderers, that sort of things was stored in ViewHints and could thus  
be saved in a 3DMF edited or viewed with that renderer. Since the per- 
pixel lighting would still be pretty much renderer-specific, using  
the ViewHints makes some sense to me.

Re: Per-pixel lighting

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

Dan Zinngrabe wrote:

> 1. Style?
> 2. View Hint (this is how it was traditionally done with plug-in 
> renderers in QD3D)

It's my understanding that a view hints object is basically a way of 
wrapping up, for 3DMF storage, information that would exist elsewhere at 
run time.  For example a view hint can record the clear image color, but 
at run time the draw context object knows the clear image color.

I'm leaning toward an object property on the renderer.  I don't envision 
a great need to use it for some objects and not others.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Per-pixel lighting

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

Il giorno 29/mar/07, alle ore 23:55, James Walker ha scritto:

> an object property on the renderer, or a new
> flavor of illumination shader, or an object property on the Phong
> illumination shader


mmm,,, difficult to say

the property in the renderer seems the easyest, but a illumination  
shader allow us to select the mode in a per object manner...

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Per-pixel lighting

[Dan Z. <que...@ma...>]

1. Style?
2. View Hint (this is how it was traditionally done with plug-in  
renderers in QD3D)

On Mar 29, 2007, at 2:55 PM, James Walker wrote:

> I'm thinking of adding a per-pixel lighting option when the hardware
> supports OpenGL Shading Language.  It would have to be an option  
> because
> it will slow down rendering some.  Any opinions as to how this option
> should be selected ... an object property on the renderer, or a new
> flavor of illumination shader, or an object property on the Phong
> illumination shader, or something else?
> -- 
>    James W. Walker, Innoventive Software LLC
>    <http://www.frameforge3d.com/>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Per-pixel lighting

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

I'm thinking of adding a per-pixel lighting option when the hardware 
supports OpenGL Shading Language.  It would have to be an option because 
it will slow down rendering some.  Any opinions as to how this option 
should be selected ... an object property on the renderer, or a new 
flavor of illumination shader, or an object property on the Phong 
illumination shader, or something else?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: More Quesa optimisation

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

Roger Holmes wrote:

> I have looked through and only found places where at least one of the  
> following applies:
> 
> The object pointer has been tested for nil beforehand.
> The object pointer has been de-referenced beforehand so would have  
> already crashed.
> The function's result is used in a way which does not allow nil.
> 
> So yes, I agree, lets change the function, only two files to change,  
> the header and the source.
> 
> Well spotted.

Thanks for the confirmation.  I've checked it in.  In a quick test, the 
Multi-Box test got about 3% faster.  Every little bit helps.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: More Quesa optimisation

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

> Is there any case in which it is not a bug for 'this' to be NULL?  I
> can't find one.  I suggest that instead of adding FastGetClass, we  
> just
> change the implementation of OpaqueTQ3Object::GetClass to
>
> Q3_ASSERT( this != NULL );
> return theClass;
>
> so that in non-debug builds it will just return theClass.  Also  
> GetClass
> could be made inline.


I have looked through and only found places where at least one of the  
following applies:

The object pointer has been tested for nil beforehand.
The object pointer has been de-referenced beforehand so would have  
already crashed.
The function's result is used in a way which does not allow nil.

So yes, I agree, lets change the function, only two files to change,  
the header and the source.

Well spotted.

Roger.

Re: More Quesa optimisation

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

Roger Holmes wrote:
> e3group_submit_render is used a great deal, recursing very deeply in  
> Microspot's applications, so Shark shows it, and the routines it  
> calls use a lot of CPU time. I have a couple of optimisations for it,  
> but lets keep it simple and do one at a time for now. It calls  
> OpaqueTQ3Object::GetClass, which (in the disassembled code)pushes a  
> register, checks that its 'this' pointer is NULL and sets the return  
> register to a field of 'this', or to NULL if 'this' was NULL, then  
> pops the register back off and actually returns.
> 
> e3group_submit_render then ignores whether the return value was NULL  
> and dereferences it.
> 
> An optimisation for this is to have an inline   
> OpaqueTQ3Object::FastGetClass which just returns the field of the  
> class. This avoids the register pop, the call, the test for NULL and  
> may allow e3group_submit_render to make better use of its registers,  
> which are somewhat more limited on Intel than they were on PowerPC.

Is there any case in which it is not a bug for 'this' to be NULL?  I 
can't find one.  I suggest that instead of adding FastGetClass, we just 
change the implementation of OpaqueTQ3Object::GetClass to

Q3_ASSERT( this != NULL );
return theClass;

so that in non-debug builds it will just return theClass.  Also GetClass 
could be made inline.

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

More Quesa optimisation

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

e3group_submit_render is used a great deal, recursing very deeply in  
Microspot's applications, so Shark shows it, and the routines it  
calls use a lot of CPU time. I have a couple of optimisations for it,  
but lets keep it simple and do one at a time for now. It calls  
OpaqueTQ3Object::GetClass, which (in the disassembled code)pushes a  
register, checks that its 'this' pointer is NULL and sets the return  
register to a field of 'this', or to NULL if 'this' was NULL, then  
pops the register back off and actually returns.

e3group_submit_render then ignores whether the return value was NULL  
and dereferences it.

An optimisation for this is to have an inline   
OpaqueTQ3Object::FastGetClass which just returns the field of the  
class. This avoids the register pop, the call, the test for NULL and  
may allow e3group_submit_render to make better use of its registers,  
which are somewhat more limited on Intel than they were on PowerPC.

I also changed e3view_submit_retained_render and E3Object_IsType to  
use the fast version as they too do not check for NULL and uses a lot  
of CPU time calling OpaqueTQ3Object::GetClass.

If nobody objects, the changes are:

In E3View.c in e3view_submit_retained_render

	E3Root* theClass = (E3Root*) theObject->FastGetClass () ;


In E3Main.c in E3Object_IsType

	return theObject->FastGetClass ()->IsType ( theType ) ;


In E3Grroup.c in e3group_submit_render

	E3GroupInfo* groupClass = (E3GroupInfo*) theObject->FastGetClass () ;


In E3Main.h in struct OpaqueTQ3Object just after the definition of  
GetClass


	E3ClassInfoPtr				FastGetClass ( void )  { return theClass ; }



Roger.

Re: New 3DS Importer-Exporter and License question

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

On Mar 24, 2007, at 5:21 AM, Jose' Cruanyes wrote:

> I'm reading a new 3DS importer-Exporter, built using the lib3ds
> library <http://lib3ds.sf.net>
>
> actually I've got the same functionality that the old 3DSreader, but
> the file is fully parsed, so adding things like colors, normals, uv
> params and so is just a matter of complete the trimesh creation  
> function
>
> from monday I,ll begin creating the exporter, always using the
> lib3ds, and packaged in the same plug-in

Sounds good!

>
> actually is only as Xcode project, Visual Studio project will follow
> soon.
>
> the problem is:
> -lib3ds is released as LPGL, so the new plug-is has to be LPGL too
> -I'd like to release the plug-is as part of Quesa
> 	How about releasing parts with different licenses?

I don't see a problem with that.

> -the new plug-in uses Code of Quesa, part written by me but
> attributed to Quesa, part written by J. Walker as the VRML plug-in
> and attributed to Quesa too
> 	so the authors had to release the code in a new license , for me
> there's not a problem (of course :-)
> 	I need also the J.Walker license...
>
> but, is enough?, having attributted the code to Quesa, may be I need
> permission of more people...

Since LGPL is more restrictive than BSD, I think that would be OK.  I  
have seen some open source code covered by 2 licenses, but I don't  
know if that would be needed.

>
> anyone has any thought?
>
> How about releasing the code as LGPL also (as originary) so anyone
> can choose the most compelling license case, by case)?

You mean all of Quesa as LGPL?  I don't see why anyone would want that.

New 3DS Importer-Exporter and License question

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

I'm reading a new 3DS importer-Exporter, built using the lib3ds  
library <http://lib3ds.sf.net>

actually I've got the same functionality that the old 3DSreader, but  
the file is fully parsed, so adding things like colors, normals, uv  
params and so is just a matter of complete the trimesh creation function

from monday I,ll begin creating the exporter, always using the  
lib3ds, and packaged in the same plug-in

actually is only as Xcode project, Visual Studio project will follow  
soon.

the problem is:
-lib3ds is released as LPGL, so the new plug-is has to be LPGL too
-I'd like to release the plug-is as part of Quesa
	How about releasing parts with different licenses?
-the new plug-in uses Code of Quesa, part written by me but  
attributed to Quesa, part written by J. Walker as the VRML plug-in  
and attributed to Quesa too
	so the authors had to release the code in a new license , for me  
there's not a problem (of course :-)
	I need also the J.Walker license...

but, is enough?, having attributted the code to Quesa, may be I need  
permission of more people...

anyone has any thought?

How about releasing the code as LGPL also (as originary) so anyone  
can choose the most compelling license case, by case)?





Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Using OS X framework

[Jeff Q. <jq...@mi...>]

On Mar 23, 2007, at 12:43 AM, Jose' Cruanyes wrote:

> Il giorno 23/mar/07, alle ore 05:57, Jeff Quan ha scritto:
>> I've been able to compile a universal binary framework, but I'm not
>> sure how to proceed. I've linked my app to a Quesa.framework folder
>> before, but what I get back is a Quesa.build folder. What are my
>> next steps?
>
>
> you can find your Framework at:
> SDK/Libraries/Mac/Framework_Universal/


Thanks, Jose! That's exactly what I needed to know.


==
Jeff Quan
jq...@mi...
http://www.jcquan.com/JQportfolio

Re: Using OS X framework

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

Il giorno 23/mar/07, alle ore 05:57, Jeff Quan ha scritto:

> I'm entirely new to Xcode and to frameworks, but I'd like to give  
> the latest Quesa's OpenGL renderer a run as I use it in conjunction  
> with REALbasic.
>
> I've been able to compile a universal binary framework, but I'm not  
> sure how to proceed. I've linked my app to a Quesa.framework folder  
> before, but what I get back is a Quesa.build folder. What are my  
> next steps?



you can find your Framework at:
SDK/Libraries/Mac/Framework_Universal/


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Using OS X framework

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

On Mar 22, 2007, at 9:57 PM, Jeff Quan wrote:

> I'm entirely new to Xcode and to frameworks, but I'd like to give  
> the latest Quesa's OpenGL renderer a run as I use it in conjunction  
> with REALbasic.
>
> I've been able to compile a universal binary framework, but I'm not  
> sure how to proceed. I've linked my app to a Quesa.framework folder  
> before, but what I get back is a Quesa.build folder. What are my  
> next steps?

I'm not sure I understand the question.  When you build the Quesa  
Xcode project, you should get a Quesa.framework inside the build  
folder.  Are you saying you didn't get that?

I can tell you how to use Quesa.framework with an app build with  
Xcode, but I don't know how it fits in with REALbasic.