quesa-develop — Mailing list for Quesa development

Re: Announcing Cartoon Renderer

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

Il giorno 11/lug/05, alle 16:25, Roger Holmes ha scritto:

> I have just done an update in Mac CVS Pro, including the .mcp
> file. I use CodeWarrior 8.3 to compile the Carbon Shared Lib
> debugging version and it cannot find CartoonRenderer.h or
> CartoonRenderer.cpp. I have searched my hard disk and
> cannot find these files. Were they not checked in or am I
> being stupid?
>
there should be an option in MacCVS to "create missing directories" or 
something like that


Pax et Bonum

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

Re: Announcing Cartoon Renderer

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

On Jul 11, 2005, at 7:25 AM, Roger Holmes wrote:

> I have just done an update in Mac CVS Pro, including the .mcp
> file. I use CodeWarrior 8.3 to compile the Carbon Shared Lib
> debugging version and it cannot find CartoonRenderer.h or
> CartoonRenderer.cpp. I have searched my hard disk and
> cannot find these files. Were they not checked in or am I
> being stupid?
>

Try doing a check out instead of an update.  I'm not sure if an  
update always gives you new files or directories.

Re: Announcing Cartoon Renderer

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

I have just done an update in Mac CVS Pro, including the .mcp
file. I use CodeWarrior 8.3 to compile the Carbon Shared Lib
debugging version and it cannot find CartoonRenderer.h or
CartoonRenderer.cpp. I have searched my hard disk and
cannot find these files. Were they not checked in or am I
being stupid?

Roger.

Re: Announcing Cartoon Renderer

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

On Jul 10, 2005, at 1:30 PM, Jose' Cruanyes wrote:

> Il giorno 09/lug/05, alle 03:49, James W. Walker ha scritto:
>
>
>> But tell me, is there some simple preprocessor condition I can use  
>> to test for the malevolent presence of VSC++ 6.0?  I am  
>> considering contributing a VRML reader to Quesa, and it is much  
>> more code than the cartoon renderer, with many ands and ors.
>>
>>
>
> the macro is _MSC_VER that for VSC 6.0 is defined >= 1200 and <1300  
> (1300 is .net, and 1400 will be VS8)
>
> we'll try with a couple of defines as you suggest, but if it's not  
> enough we can just declared the plug-in not compatible with the  
> ancient compiler

Come to think of it, it is likely to be incompatible.  The plug-in  
uses the Spirit parser library (part of Boost), which heavily uses  
template metaprogramming.  I even ran into a compiler bug in  
CodeWarrior 9.5.

Re: Announcing Cartoon Renderer

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

Il giorno 09/lug/05, alle 03:49, James W. Walker ha scritto:

> But tell me, is there some simple preprocessor condition I can use to 
> test for the malevolent presence of VSC++ 6.0?  I am considering 
> contributing a VRML reader to Quesa, and it is much more code than the 
> cartoon renderer, with many ands and ors.
>

the macro is _MSC_VER that for VSC 6.0 is defined >= 1200 and <1300 
(1300 is .net, and 1400 will be VS8)

we'll try with a couple of defines as you suggest, but if it's not 
enough we can just declared the plug-in not compatible with the ancient 
compiler


Pax et Bonum

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

Re: Announcing Cartoon Renderer

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

Jose' Cruanyes <cru...@ce...> wrote:

>>   This is not just a cosmetic issue, you are copying data that was 
>>not being copied before, inside a loop.
>
>I've found a workaround (an uber ugly one)

Thanks, I can live with that.

But tell me, is there some simple preprocessor condition I can use to 
test for the malevolent presence of VSC++ 6.0?  I am considering 
contributing a VRML reader to Quesa, and it is much more code than 
the cartoon renderer, with many ands and ors.

Speaking of which, anyone know about the SourceForge feature of 
subprojects and tasks?  They don't have any documentation on that, so 
I don't know whether a subproject would be appropriate for a plug-in.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

Il giorno 08/lug/05, alle 18:54, James W. Walker ha scritto:

> Surely VC6 is capable of making a reference.

err.., is about VSC++ 6.0 we're talking :-(

the problem is that the declaration is too complex :-!


>  This is not just a cosmetic issue, you are copying data that was not 
> being copied before, inside a loop.

I've found a workaround (an uber ugly one)

>
Pax et Bonum

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

Re: Announcing Cartoon Renderer

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

Jose' Cruanyes <cru...@ce...> wrote:

>I've noted that sometimes the Cartoon renderer misses some polys, 
>but I cant see a pattern, you can see it loading in Geom Test 
>"PodRacer.3dmf"
>this is a bug or a feature?
>it happens with some of my models too...

In the PodRacer, one of the TriMeshes lacks vertex normals.  The 
cartoon shading algorithm needs vertex normals.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

>Done ( but I know you don't like the "port" to VS6 ;-)
>

Oh, no, my lovely ands, ors, and nots!  I may have to buy VC7 just to 
avoid this. :-)

Or, I suppose I could do something like

#if _SOME_WAY_TO_DETECT_STUPID_COMPILER_
	#define and &&
	#define or ||
	#define not !
#endif


But what was the reason for this change?

*** 603,607 ****
   		for (int faceNum = 0; faceNum < outNumFaces; ++faceNum)
   		{
! 			const TQ3TriMeshTriangleData& faceData( 
inData.triangles[faceNum] );

   			for (int vertNum = 0; vertNum < 3; ++vertNum)
--- 606,610 ----
   		for (int faceNum = 0; faceNum < outNumFaces; ++faceNum)
   		{
! 			const TQ3TriMeshTriangleData faceData( 
inData.triangles[faceNum] );

   			for (int vertNum = 0; vertNum < 3; ++vertNum)

Surely VC6 is capable of making a reference.   This is not just a 
cosmetic issue, you are copying data that was not being copied 
before, inside a loop.


>I've noted that sometimes the Cartoon renderer misses some polys, 
>but I cant see a pattern, you can see it loading in Geom Test 
>"PodRacer.3dmf"
>this is a bug or a feature?
>it happens with some of my models too...


I'll look into it.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

QUESA_OS_COCOA

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

I was playing a bit with quesa and trying to compile the Cocoa sample 
(broken)

and wondering...

QuesaCocoa should't be a superset of Quesa Mach-O?
  I mean Quesa Mach-O with the Cocoa drawcontext on top?



Pax et Bonum

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

Re: Announcing Cartoon Renderer

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

Il giorno 08/lug/05, alle 11:19, Jose' Cruanyes ha scritto:

> Hope to update the unix build soon too
>

Done, but sourceforge gives me an error trying to send the mail

Pax et Bonum

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

Re: Announcing Cartoon Renderer

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

Il giorno 07/lug/05, alle 20:14, James W. Walker ha scritto:

>
> Now, if someone could update the MS Visual C++ project, I think we'll 
> be done.
> -- 

Done ( but I know you don't like the "port" to VS6 ;-)

Hope to update the unix build soon too

I've noted that sometimes the Cartoon renderer misses some polys, but I 
cant see a pattern, you can see it loading in Geom Test "PodRacer.3dmf"
this is a bug or a feature?
it happens with some of my models too...

Pax et Bonum

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

Re: Announcing Cartoon Renderer

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

>I attempted to update the XCode project using XCode 1.5, and got an
>error message saying "Undefined Symbols:".  That's it, no mention of
>what symbols might be undefined.  I wonder if we should update to
>XCode 2.1 anyway?

Never mind, I got the XCode project fixed.

Now, if someone could update the MS Visual C++ project, I think we'll be done.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

I attempted to update the XCode project using XCode 1.5, and got an  
error message saying "Undefined Symbols:".  That's it, no mention of  
what symbols might be undefined.  I wonder if we should update to  
XCode 2.1 anyway?

Re: Announcing Cartoon Renderer

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

On Jul 7, 2005, at 6:09 AM, Jose' Cruanyes wrote:

> Are you sure you have commited all the changes?
> where is it registered?
> have you updated any project? (xcode, CW, ecc)

Excellent questions.  Apparently I'm an idiot.  I just checked in  
E3System.c to register it, and checked in changes to the CodeWarrior  
projects.

There's one thing I'm uncertain about concerning the Window project.   
The cartoon renderer includes <GL/glext.h>.  This file is apparently  
not a standard part of the Win32 SDK, but can be downloaded from  
<http://oss.sgi.com/projects/ogl-sample/ABI/glext.h>.  So, should  
Quesa provide that file, someplace other than the standard GL  
directory, or trust people to find it, or what?

Re: Announcing Cartoon Renderer

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

Il giorno 07/lug/05, alle 03:20, James W. Walker ha scritto:

> I have just finished committing a cartoon-style renderer.  The 
> programming was started by a Siberian programmer going by the name 
> Lloyd Bridges, under contract to ScriptPerfection Enterprises, and 
> finished by me.  I do not claim that the code is pretty or 
> bulletproof, but it is enough for my purposes.  This renderer is 
> implemented as part of Quesa, rather than as a plug-in, because it 
> calls a couple of internal functions of the Interactive Renderer.
>

Are you sure you have commited all the changes?
where is it registered?
have you updated any project? (xcode, CW, ecc)


thanks a lot

PS [OT]
you, as a cross-platform codewarrior as me, what options have you 
considered?
just split xcode <-> Visual Studio and get yourself another laptop 
(windows this time)?
try to use mingw on mac?
other?



Pax et Bonum

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

Announcing Cartoon Renderer

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

I have just finished committing a cartoon-style renderer.  The 
programming was started by a Siberian programmer going by the name 
Lloyd Bridges, under contract to ScriptPerfection Enterprises, and 
finished by me.  I do not claim that the code is pretty or 
bulletproof, but it is enough for my purposes.  This renderer is 
implemented as part of Quesa, rather than as a plug-in, because it 
calls a couple of internal functions of the Interactive Renderer.

The main idea of cartoon-style rendering is to use relatively few 
distinct colors, giving a look that is somewhat "flat" but not as 
flat as using the NULL illumination shader or using nothing but 
ambient light.  We also wish to emphasize the outlines.

Usage:  One way to get the Cartoon renderer is to enumerate 
subclasses of the renderer class, as the Geom Test sample does. 
Another way would be to use code like this:

	TQ3ObjectType	cartoonType;
	Q3ObjectHierarchy_GetTypeFromString( "Quesa Cartoon", &cartoonType );
	TQ3RendererObject	theRenderer = Q3Renderer_NewFromType( 
cartoonType );

A TriMesh can be forced to be rendered by the standard interactive 
renderer by attaching an object property of type 'NCar'.  The data in 
the property does not matter.  Transparent trimeshes will always be 
rendered by the interactive renderer.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

ViewHints I/O (was Lights I/O)

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

I did some testing tonight. Below I'm listing the changes that I've 
made in order to write QD3D compatible viewhints. Now camera, lights, 
attributes, color, and dimensions will be written.

>>QD3D always writes the whole ViewHints data. In
>>   e3viewhints_new (file E3IOData.c)
>>this behaviour is partly implemented (if paramData...): Camera and 
>>lights are ok, renderer is basically ok (as you mentioned above: 
>>depends on the renderer type), default attributes should use 
>>Q3View_GetDefaultAttributeSet (not Q3View_GetAttributeSetState, I 
>>suppose), and clear color/dimension should be initialized from the 
>>draw context data.
>
>Why should we use Q3View_GetDefaultAttributeSet instead of 
>Q3View_GetAttributeSetState ?

Q3View_GetAttributeSetState does not work. There are two functions to 
set/get the attribute to/from a view called 
Q3View_Set/GetDefaultAttributeSet. That' why I tried to use 
Q3View_GetDefaultAttributeSet. I wrote two files under QD3D with 
different attribute values, read and rewrote them under Quesa. Well, 
it works!

>>>I do not need backward compatibility but I would like to sort this out
>>>for you if you do need it. Any chance of patching the file to find
>>>out which particular aspect is tripping up QD3D?
>>
>>Currently I have not found a particular aspect; ignoring the 
>>viewhints as well as reading the complete viewhints seems to work. 
>>Certainly, I'm missing something, but what?
>>
>>My suggestions are:
>>- upload the "kQ3LightData as 'lhgt'" hack

Could you upload the "kQ3LightData as 'lhgt'" in E3FFW_3DMFBin_Writer.c?

>>- change e3viewhints_new (the "if paramData" section)

The clear image color works well.
The dimension should be max - min as you mentioned in the code 
(Q3DrawContext_GetPane/Q3DrawContext_GetPaneState).

>
>
>>- Quesa renderers: write the renderer settings out
>
>This is a job for the someone familiar with the interactive renderer 
>code. Its not part of View Hints, I am asking the Renderer to write 
>itself out.

It would be nice to do this for interactive and wireframe renderer... 
But it's not that important for me.

Stefan

Display lists, etc., comments from Dair

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

"Mikey" recently asked why Quesa does not use display lists.  This 
led me to ask Dair Grant a couple of questions, and (with his 
permission) here are the responses.

>1.  Why doesn't the interactive renderer use OpenGL display lists?

The history of "fast drawing" in OpenGL has changed over time - display
lists were really the only option originally, however these were fairly
quickly replaced with glDrawElements.

The modern approach is to use VARs/VOBs, which are basically a way to
allocate geometry in VRAM and synchronise the CPU with the GPU when it
comes to manipulating that data.

This lets the CPU lock the data when it needs to update, unlock when
done, and then get on with other work while the GPU is pulling the data
across for processing.

The mantra nowadays is that you get the best performance by minimising
contention between the CPU and GPU - in the best case, they should be
running entirely in parallel so that one is never blocked on the other.

That was the kind of direction I was hoping to go in eventually; the
TriMesh has a lock/unlock API now which would make that quite feasible,
as all that would need to happen would be the renderer provide the
ability to allocate/lock/unlock a "geometry object" (== VOB or whatever,
but exposed as an opaque type to the rest of the system so the core lib
didn't have to know it was sitting on top of VOBs/VARs/Apple_fence, etc)
and then the higher level API uses that to copy changes in as necessary.


I didn't really do much investigation into the benefits of using display
lists to capture rendering state (which is the other thing they're handy
for), as from what I've seen when porting games over to the Mac they're
rarely used in those circumstances.

Typically people will have their own little state buffer to avoid
pushing redundant changes down, and then a geometry manager that looks
after a circular list of vertex buffers - as data comes down for
rendering, it gets copied into buffers and submitted with glDrawElements
(although there's normally a lock/unlock model on top of this, so I
assume most people are moving to the VBO approach too).


>2.  Why does the IR do its own backface culling instead of letting
>OpenGL do it?
>
>These are related because we'd have to lose the backface culling in
>order to use display lists effectively.  We wouldn't want to have to
>flush cached display lists every time the camera moves.

The IR does its own backface culling because unfortunately GL's culling
is less expressive than the options QD3D provides.

I forget the exact details (I think there's plenty of comments
hopefully; I have a feeling I posted a big summary to the list for
posterity at some point), but it's to do with the orientation style.

IIRC, GL does its culling based on the screen projection of the vertices
or something - while in QD3D it's more complicated, and the various
permutations of culling styles (including flip) and orientation styles
means you can't implement QD3D's model on top of GL.

Bit fuzzy, I know, but I think this was a long-standing problem for
Interstudio which we finally fixed by handling all culling ourselves
rather than trying to let GL handle it in some cases (if you grep for
everywhere orientation and culling styles are mentioned, you might find
the comments).


In terms of if switching to display lists will be the best solution, I'm
not sure it would be. It's definitely the right idea (the more you let
GL manage data the better, as it gives it a chance to live in faster
memory), but it's not the "modern" approach.

I would look at VBOs/VARs before making any big decisions, and see how
basing something on top of them would fit (or even APPLE_fence: the key
idea which takes them beyond display lists is that they give you more
opportunities to avoid contention between CPU and GPU, which is the key
to getting good performance nowadays).

What might be worth doing is breaking the IR down into an "interactive
renderer" and a "rendering engine". I.e., build a couple of objects
which provide:

   - Texture management
   - State management
   - Geometry (vertex and index) management

And move all the GL code inside them. They should expose the bare
minimum, and then all the more QD3D-related code can live in the IR as
an intermediate between the scene graph (the QD3D library) and the
actual rendering API (GL/D3D/etc).

That would mean the IR would really just handle state buffering,
geometry decomposition, view state stack, etc - and means you can have
some lower level services which are effectively QD3D-independent means
to talk to a modern graphics card and deal with the four key things
they're based around (textures, state, geometry, and shaders).

Kind of like resurrecting RAVE I suppose, but designed with a "you need
to lock if you want acess to data, and unlock when you're done" model
that would allow you to dump data into VARs/VBOs - or even record
snapshots into display lists which you then play back, if that did turn
out to be faster (but I'm not sure it will be: I've only see one game
that used display lists, and they had it #if'd off for the PC version so
we never bothered turning it on for the Mac).

I think that's something the IR suffered from a bit - in retrospect, it
would have been better to write a "simple 3D engine based on modern GL
which doesn't expose GL types/APIs" engine first, and then write a
"translate from QD3D world to our engine" second to form the IR.


-dair (one other reason for VBO/etc is that it's quite suitable for
hooking up to vertex shaders for animation/etc - display lists really
predate programmability, so I don't think they would turn out to be very
useful if you also wanted to explore shaders one day)

(i.e., once you've recorded a display list the data is locked away
inside: but for shaders you need to be able to tell the shader where to
read data from via (effectively) a pointer to the geometry data - the
pointer may be on the card and so unmapped to you, but you can still
pass the value around even if you're not allowed to read from it (the
shader can read from it since it'll be on the card too))

-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Lights I/O

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

On 3 Jul, 2005, at 17:34, Stefan Huber wrote:

> I've found several aspects to improve viewhints i/o in Quesa.
>
>> Going through the different parts in turn:
>>
>> The renderer is missing because whoever wrote the interactive
>> renderer forgot to write the code which writes it out, however,
>> this does not seem to be much of a problem, as any other
>> QD3D renderer does have this code. For instance
>> if the Microspot renderer was selected at save time, the
>> renderer does get written. If there is no renderer we default
>> to the interactive renderer and all is well. I guess this might
>> be a problem for you but I doubt it.

Strange to comment on my own comments, but I have tried out my old OS8 
code
and the first thing it gets out of the View Hints is the Renderer. If 
there isn't one
it throws an exception and does not read the rest of the view hints.

>
> In Quesa it's not really a problem for me, but it might be a problem 
> with backward compability (see below). But IR_TextureFilterMode would 
> be quite useful (in QD3D writing texture filter mode seems not to 
> work).
>
>> I am surprised about the container around the individual lights,
>> the documentation for the 3D Meta File format shows them as
>> loose items.
>
> The documentation is not perfect; some information is not compatible 
> with 3DMF version 1.5/1.6. I think we should use the v1.6 output as a 
> reference.

OK

>
>> The code for writing out the attribute set, the clear colour and the
>> image dimensions is there, though it does not get called unless
>> you add these items to the view hints object. Maybe I am missing
>> something here.
>
> QD3D always writes the whole ViewHints data. In
>   e3viewhints_new (file E3IOData.c)
> this behaviour is partly implemented (if paramData...): Camera and 
> lights are ok, renderer is basically ok (as you mentioned above: 
> depends on the renderer type), default attributes should use 
> Q3View_GetDefaultAttributeSet (not Q3View_GetAttributeSetState, I 
> suppose), and clear color/dimension should be initialized from the 
> draw context data.

Why should we use Q3View_GetDefaultAttributeSet instead of 
Q3View_GetAttributeSetState ?

>
>> I do not need backward compatibility but I would like to sort this out
>> for you if you do need it. Any chance of patching the file to find
>> out which particular aspect is tripping up QD3D?
>
> Currently I have not found a particular aspect; ignoring the viewhints 
> as well as reading the complete viewhints seems to work. Certainly, 
> I'm missing something, but what?
>
> My suggestions are:
> - upload the "kQ3LightData as 'lhgt'" hack
> - change e3viewhints_new (the "if paramData" section)


> - Quesa renderers: write the renderer settings out

This is a job for the someone familiar with the interactive renderer 
code. Its not part of View Hints, I am asking the Renderer to write 
itself out.

The best I can do for this (and it works for my OS8 app code) is when 
creating an empty View Hints, I set the renderer to the interactive one 
by
default. As this code almost certainly only get called by the View Hint 
reading code, then if there isn't a renderer in the view hints then the
default interactive renderer will not get overwritten.


Roger

Re: Lights I/O

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

I've found several aspects to improve viewhints i/o in Quesa.

>Going through the different parts in turn:
>
>The renderer is missing because whoever wrote the interactive
>renderer forgot to write the code which writes it out, however,
>this does not seem to be much of a problem, as any other
>QD3D renderer does have this code. For instance
>if the Microspot renderer was selected at save time, the
>renderer does get written. If there is no renderer we default
>to the interactive renderer and all is well. I guess this might
>be a problem for you but I doubt it.

In Quesa it's not really a problem for me, but it might be a problem 
with backward compability (see below). But IR_TextureFilterMode would 
be quite useful (in QD3D writing texture filter mode seems not to 
work).

>I am surprised about the container around the individual lights,
>the documentation for the 3D Meta File format shows them as
>loose items.

The documentation is not perfect; some information is not compatible 
with 3DMF version 1.5/1.6. I think we should use the v1.6 output as a 
reference.

>The code for writing out the attribute set, the clear colour and the
>image dimensions is there, though it does not get called unless
>you add these items to the view hints object. Maybe I am missing
>something here.

QD3D always writes the whole ViewHints data. In
   e3viewhints_new (file E3IOData.c)
this behaviour is partly implemented (if paramData...): Camera and 
lights are ok, renderer is basically ok (as you mentioned above: 
depends on the renderer type), default attributes should use 
Q3View_GetDefaultAttributeSet (not Q3View_GetAttributeSetState, I 
suppose), and clear color/dimension should be initialized from the 
draw context data.

>I do not need backward compatibility but I would like to sort this out
>for you if you do need it. Any chance of patching the file to find
>out which particular aspect is tripping up QD3D?

Currently I have not found a particular aspect; ignoring the 
viewhints as well as reading the complete viewhints seems to work. 
Certainly, I'm missing something, but what?

My suggestions are:
- upload the "kQ3LightData as 'lhgt'" hack
- change e3viewhints_new (the "if paramData" section)
- Quesa renderers: write the renderer settings out

After changing these issues, the Quesa viewhints output should be 
absolutely the same as the QD3D output.

Thanks a lot and best regards,

Stefan

Re: Anybody using the pre/post submit callbacks?

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

Microspot do not use these. The small extra overhead and the extra
complexity do not worry me greatly but it would be better without them.
I doubt if anyone else (other than yourself) uses them, if so then they
should please speak now or be prepared to have to modify their code
to the new API.




On 1 Jul, 2005, at 03:20, James W. Walker wrote:

> A while back I added a callback mechanism specified via custom 
> elements:
>
> kQ3CallbackElementTypeBeforeRender
> kQ3CallbackElementTypeAfterRender
> kQ3CallbackElementTypeBeforePick
> kQ3CallbackElementTypeAfterPick
>
> I just realized that we could take a different approach which would be 
> more powerful and have less overhead.  One could create a custom 
> subclass of the View class, and override appropriate methods such as 
> submit-retained-for-rendering.  To make this possible, I would need to 
> make a couple of simple changes in E3View.c, and define some method 
> type constants in some public header.
>
> One nice thing about the approach I am suggesting is that you wouldn't 
> need separate before and after functions.  You could just do some 
> stuff before, call through to the standard method, and then do some 
> more stuff.   Furthermore, your method could actually submit a 
> different object than was passed to you, which is not possible with 
> the current callbacks.
> -- 
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Anybody using the pre/post submit callbacks?

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

A while back I added a callback mechanism specified via custom elements:

kQ3CallbackElementTypeBeforeRender
kQ3CallbackElementTypeAfterRender
kQ3CallbackElementTypeBeforePick
kQ3CallbackElementTypeAfterPick

I just realized that we could take a different approach which would 
be more powerful and have less overhead.  One could create a custom 
subclass of the View class, and override appropriate methods such as 
submit-retained-for-rendering.  To make this possible, I would need 
to make a couple of simple changes in E3View.c, and define some 
method type constants in some public header.

One nice thing about the approach I am suggesting is that you 
wouldn't need separate before and after functions.  You could just do 
some stuff before, call through to the standard method, and then do 
some more stuff.   Furthermore, your method could actually submit a 
different object than was passed to you, which is not possible with 
the current callbacks.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Lights I/O

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

Going through the different parts in turn:

The renderer is missing because whoever wrote the interactive
renderer forgot to write the code which writes it out, however,
this does not seem to be much of a problem, as any other
QD3D renderer does have this code. For instance
if the Microspot renderer was selected at save time, the
renderer does get written. If there is no renderer we default
to the interactive renderer and all is well. I guess this might
be a problem for you but I doubt it.

I am surprised about the container around the individual lights,
the documentation for the 3D Meta File format shows them as
loose items.

The code for writing out the attribute set, the clear colour and the
image dimensions is there, though it does not get called unless
you add these items to the view hints object. Maybe I am missing
something here.

I do not need backward compatibility but I would like to sort this out
for you if you do need it. Any chance of patching the file to find
out which particular aspect is tripping up QD3D?

Best regards,

Roger.




On 24 Jun, 2005, at 01:14, Stefan Huber wrote:

> I've written two simple binary files with my app: one using QD3D and 
> the other using Quesa (using your patch). Then I compared the 
> viewhints (byte for byte).
>
> In my case QD3D has written
>
> Container
>   ViewHints
>   Container (view angle aspect camera...)
>   Container (renderer...)
>   Container (ambient light...)
>   Container (direct light...)
>   Container (attribute set...)
>   ImageClearColor
>   ImageDimensions
>
> and Quesa:
>
> Container
>   ViewHints
>   Container (view angle aspect camera...)
>   Container (ambient light...)
>   Container (direct light...)
>
>
> Quesa currently seems to ignore certain parts. But the other parts are 
> absolutely binary compatible with the QD3D output. The size of the 
> main container has been correctly calculated.
>
> But QD3D has not accepted the file. Then I copied the viewhints of the 
> QD3D file into the Quesa file (Quesa geometry with QD3D viewhints): 
> QD3D can read this.
>
> It doesn't seem to be a container problem. Maybe QD3D wants the whole 
> stuff...
>
> Stefan
>
>
>
>> I have modified my version of Quesa as Stephan requested but it seems 
>> no better.
>> If you would like to try it, in E3FFW_3DMFBin_Writer.c, line 542 
>> reads:
>>
>> 					qd3dStatus = 
>> Q3Uns32_Write(instanceData->stack[i].objectType,theFile);
>>
>> If you change this (yes I know its a horrible way to do it) to:
>>
>> 					{
>> 					if ( instanceData->stack[i].objectType == kQ3LightData )
>> 						qd3dStatus = Q3Uns32_Write ( kQ3ShapeTypeLight, theFile ) ; // 
>> To allow light data objects to be read by QD3D
>> 					else
>> 						qd3dStatus = 
>> Q3Uns32_Write(instanceData->stack[i].objectType,theFile);
>> 					}
>>
>>  Then this produces the requested data in the output file.
>>
>> I think the other problem may be that the light is in a 'container' 
>> which QD3D does
>> not expect, but I have no idea how to get rid of the container, it 
>> seems everything
>> in Quesa has to be in a container whether you want it or not.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

[ quesa-Bugs-902592 ] TriMesh Colours go to the wrong faces

[SourceForge.net <no...@so...>]

Bugs item #902592, was opened at 2004-02-23 03:00
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902592&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Sanham (tomsanham)
Assigned to: Nobody/Anonymous (nobody)
Summary: TriMesh Colours go to the wrong faces

Initial Comment:
Quesa 1.6d18
OS used: Windows XP (not tested on Mac)

This bug affects cube shaped TriMeshes with 8 vertices 
which specify a colour attribute per face.

I believe that the described behaviour occurs because 
the model has >1 faces referencing the same vertex.


Behaviour:
The following strange behaviour was observed:

Setting Attribute 0 controls faces 0,4,5
Setting Attribute 1 controls face 1
Setting Attribute 2 controls faces 2,6,7,8,9,10
Setting Attribute 3 controls faces 3,11
Setting Attributes 4..11 has no visual effect

The same model renders correctly under QD3D - 
attribute n controls face n for 0<=n<12.


Workaround:
An effective workaround is to build the cube with 
duplicate vertices such that no vertex is shared by two 
faces.

Example trimesh included as a 3DMF.
Best viewed with kQ3InterpolationStyleNone

.triMeshAttributeSet = 0
.numTriangles = 12
.*triangles = 
    (4,6,2) ,
    (4,2,0) ,
    (1,3,7) ,
    (1,7,5) ,
    (5,7,6) ,
    (5,6,4) ,
    (0,2,3) ,
    (0,3,1) ,
    (2,6,3) ,
    (3,6,7) ,
    (4,0,1) ,
    (4,1,5) 
.numTriangleAttributeTypes = 1
.triangleAttributeTypes =
    .attributeType = kQ3AttributeTypeDiffuseColor
    .data =
    (1,0,0),
    (1,1,1),
    (1,1,1),
    remaining 9 faces (1,1,1)
.numEdges = 0
.edges = 0
.numEdgeAttributeTypes = 0
.*edgeAttributeTypes = 0
.numPoints = 8
.*points = 
    (0,0,0),
    (1,0,0),
    (0,1,0),
    (1,1,0),
    (0,0,1),
    (1,0,1),
    (0,1,1),
    (1,1,1)
.numVertexAttributeTypes =  0
.*vertexAttributeTypes = 0
.bBox = (0,0,0) , (10,10,10) , kQ3False

----------------------------------------------------------------------

>Comment By: James W. Walker (jwwalker)
Date: 2005-06-26 00:32

Message:
Logged In: YES 
user_id=433183

Quesa does not handle per-face colors correctly, it only uses them to infer 
vertex colors.  Therefore you get smooth color gradations when you 
expected sharp boundaries.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902592&group_id=45158