quesa-develop — Mailing list for Quesa development

Re: Time for Classic Mac to go?

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

Il giorno 10/lug/07, alle ore 14:19, Roger Holmes ha scritto:

>
> On 9 Jul, 2007, at 17:27, James W. Walker wrote:
>
>> OK, I have updated E3MacSystem.c and E3MacStorage.c.  Now the only
>> deprecation warnings I get are from the viewer.  I'm not sure if I
>> want to rewrite that.
>
> Currently, we don't use it. Does anyone?
>
> Is so votes for Cocoa vs Carbon please.
>
> Does anyone use it in a non Mac environment?

We're using the Viewer in Carbon, and we're (we were,will) porting it =20=

to win32 (and probably for GTK), we're 'employing' CS students, and =20
planning is somewhat fluid :-), but some things are coming along not =20
bad...


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: Time for Classic Mac to go?

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

On 9 Jul, 2007, at 17:27, James W. Walker wrote:

> OK, I have updated E3MacSystem.c and E3MacStorage.c.  Now the only
> deprecation warnings I get are from the viewer.  I'm not sure if I
> want to rewrite that.

Currently, we don't use it. Does anyone?

Is so votes for Cocoa vs Carbon please.

Does anyone use it in a non Mac environment?

[ quesa-Bugs-907866 ] DisplayGroupBBox object not handled

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

Bugs item #907866, was opened at 2004-03-01 13:29
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907866&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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: DisplayGroupBBox object not handled

Initial Comment:
"We have to match the group bounding box handling with QD3D, 
both for IO an in implementation, culling ecc."

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-07-09 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 2007-06-25 09:03

Message:
Logged In: YES 
user_id=433183
Originator: NO

DisplayGroupBBox is now read and written.

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

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

Re: Time for Classic Mac to go?

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

OK, I have updated E3MacSystem.c and E3MacStorage.c.  Now the only  
deprecation warnings I get are from the viewer.  I'm not sure if I  
want to rewrite that.

Re: Time for Classic Mac to go?

[Sean M. <se...@ro...>]

On 7/8/07 2:44 PM, James W. Walker said:

>Now that I'm thinking about removing deprecated and otherwise dusty  
>code, do we still need to support Classic=3F  I'm not talking about  
>assuming OS X yet, we could still run under OS 9 with Carbon.

I encourage this. :)  Frankly, I'd drop anything before 10.3.9.  I think
if Quesa is to have any hope of working in 64 bit, some old stuff will
need to go.

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Time for Classic Mac to go?

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

On 8 Jul, 2007, at 22:44, James W. Walker wrote:

> Now that I'm thinking about removing deprecated and otherwise dusty
> code, do we still need to support Classic?  I'm not talking about
> assuming OS X yet, we could still run under OS 9 with Carbon.


Fine with me too, and I wouldn't mind dropping OS9 either.

I don't use Carbon even on OS-X at the moment but might need to in  
the future.

Re: Time for Classic Mac to go?

[Sauro A. <int...@in...>]

We will stop to support Mac Os Classic for all the new version of our 
programs, so it's ok for me.

Sauro


>Now that I'm thinking about removing deprecated and otherwise dusty 
>code, do we still need to support Classic?  I'm not talking about 
>assuming OS X yet, we could still run under OS 9 with Carbon.
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Time for Classic Mac to go?

[<jo...@st...>]

On Jul 08, 2007, at 21:44 UTC, James W. Walker wrote:

> Now that I'm thinking about removing deprecated and otherwise dusty  
> code, do we still need to support Classic?  I'm not talking about  
> assuming OS X yet, we could still run under OS 9 with Carbon.

Seems fine to me.  Classic is quite old now, and if somebody really
does still need to run a 3D app under Classic, they can use QD3D.

As for me, pretty much all my Quesa usage is via REALbasic, and RB
dropped Classic support half a year ago.

Best,
- Joe

--
Joe Strout -- jo...@st... | Fusion power may be practical today.  See:
Strout Custom Solutions, LLC | http://www.strout.net/info/science/polywell

Re: Time for Classic Mac to go?

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

Il giorno 08/lug/07, alle ore 23:44, James W. Walker ha scritto:

> Now that I'm thinking about removing deprecated and otherwise dusty
> code, do we still need to support Classic?  I'm not talking about
> assuming OS X yet, we could still run under OS 9 with Carbon.

No problems for me (I've OS9 users but they are using carbon)



Pax et Bonum

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

Time for Classic Mac to go?

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

Now that I'm thinking about removing deprecated and otherwise dusty  
code, do we still need to support Classic?  I'm not talking about  
assuming OS X yet, we could still run under OS 9 with Carbon.

Re: Time to trash DrawRegions?

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

Il giorno 08/lug/07, alle ore 21:15, James W. Walker ha scritto:

>  I don't know how to test the Unix build

It has been left a bit behind...

I'll try to put it on track again shortly...



Pax et Bonum

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

Added the radius attribute to the point light

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

After several tries I've decided to not create an spherical light, =20
but just add the possibility of store the radius in the existing =20
point light...

so I've added two functions in the Quesa API:

Q3PointLight_SetRadius
Q3PointLight_GetRadius

using this functions you can still use the old point light, and the =20
renderers that not support spherical lights can just ignore the =20
radius...

I've also updated RayShade to use the radius, unfortunately there's =20
some problem in the antialiasing code and the result is not so good =20
as we expect, but worth testing nonetheless.

I'd choose to not use a property to make the radius an integral part =20
of the point light.


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: Time to trash DrawRegions?

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

Draw regions are gone.  I don't know how to test the Unix build, but  
I don't see anything related to draw regions in E3UnixDrawContext.c.

[ quesa-Bugs-901427 ] Implement visibility culling

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

Bugs item #901427, was opened at 2004-02-20 14:39
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901427&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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: Implement visibility culling

Initial Comment:
Implement the kQ3XMethodTypeRendererIsBoundingBoxVisible 
method for OpenGL renderers, and make use of this when 
submitting groups with bounding boxes.

Was discussed on the mailing list, and a proposal was:
        
--------------------------------
> Do you see this general-purpose test in QuesaMath.h as 
something
> we would expose to users, or something only for internal use?

I think it's similar to the Q3Ray3D_IntersectXXX routines: these 
were written internally for the picking code (E3Utils.c is a good 
place for these to live temporarily until you firm up the interface), 
but they're really general purpose 3D utilities.

A general visibility test routine would be useful in other 
circumstances (perhaps you have your own data structure for 
organising the world: if you can derive a bounding box from it, you 
could use this routine to do your own culling), and it would also be 
useful to have a bounding-sphere version as well.


These are quicker, if less accurate, so perhaps what we need is:

  typedef enum TQ3Visibility {
     kQ3VisibleIsNot              = 0, // kQ3False
     kQ3VisibleCompletely         = 1, // kQ3True
     kQ3VisiblePartially          = 2,
  } TQ3Visibility;

  TQ3Visibility Q3BoundingBox_IsVisible(box, TQ3View-or-camera-
spec)
  TQ3Visibility Q3BoundingSphere_IsVisible(sphere, TQ3View-or-
camera-spec)

Currently the IsBoundingBox renderer method returns a 
TQ3Boolean.

It would be useful to change this to return one of these visibility 
enums, so we could do this in a binary compatible manner by 
having the first two enum values correspond to the values for 
kQ3False/kQ3True.

It wouldn't be source compatible, but a)it's a simple cast to fix and 
b)the only code I know of that uses this method is the code in 
QD3D that queries the QD3D IR.


The reason for changing the return type is it'd be useful to add an 
IsBoundingSphere method to renderers as well.

Both box and sphere methods would be implemented just by calling 
on to the Q3BoundingXXX_IsVisible methods for our IR, but this 
would mean Quesa could be a bit smarter.


>> 2. When submitting a display group with a bounding box, call 
the
>> method to decide if the group really needs to be submitted.

I.e., this test (or any bounding box test) could now be:

- Call the IsBoundingSphere method. This gives you a fast test, and 
if it returns kQ3VisibleIsNot or kQ3VisibleCompletely then you're 
done.

- If it returns kQ3VisiblePartially, call the IsBoundingBox method. 
This takes longer, but gives you a better decision for some edge 
cases.

I suppose you could implement the above simply by sticking to 
bools and having the Q3BoundingBox_IsVisible do an internal test 
on a bounding sphere first and then on the box, but having both 
methods available would be more flexible.


Flexible in that there's an OpenGL extension where you can hint 
that the geometry is entirely visible on the screen (rather than 
partially clipped) for a slight performance boost.

If we were able to pass back an enum rather than a bool then we'd 
be able to identify this case in the future and use the extension if 
it's present.
--------------------------------


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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-07-07 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 2007-06-23 18:22

Message:
Logged In: YES 
user_id=433183
Originator: NO

Visibility culling is now implemented for the built-in renderers, though
some of the suggestions were not adopted (no use of bounding spheres, no
partial visibility result).

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

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

Re: Time to trash DrawRegions?

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

On 6 Jul, 2007, at 20:04, James Walker wrote:

> Is anyone using any plug-in renderers that need draw region  
> support?  If
> not, I'd like to get rid of draw regions and simplify some of the draw
> context code.


At last I know what they are. Yes please get rid of them, even though  
I will need to modify my renderer, it will improve readability.

Roger.

Re: Wireframe Renderer

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

Il giorno 06/lug/07, alle ore 21:22, Lane Roathe ha scritto:

>
>> Would anyone object if I removed the corresponding binary project =20
>> files
>> (.mcp)?  I don't want to bother to update them, and I worry that =20
>> these
>> old project files might confuse someone who downloads Quesa.  The =20
>> only
>> down side I see is that we lose the cvs history.


removing a file in CVS doesn't lost its history, the file is moved to =20=

a folder called ATTIC, and you can take it out using date, revisions =20
or tag...


>
> You might try bringing the project over to svn on SF. I'm not sure =20
> if it
> brings over the history or not, as I haven't had time to do this on my
> projects. But, if it does, then you could delete the binary files and
> the history would remain in svn.

moving to svn is something we have to definitely consider, but for =20
experience is not a trivial thing to do, I don't know if there is =20
some support for that on SF, but I know that I've no time at the =20
moment to devote to that.


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: Time to trash DrawRegions?

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

Il giorno 06/lug/07, alle ore 21:04, James Walker ha scritto:

> Is anyone using any plug-in renderers that need draw region =20
> support?  If
> not, I'd like to get rid of draw regions and simplify some of the draw
> context code.
>

OK for me...


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: Wireframe Renderer

[Lane R. <la...@if...>]

on Fri, Jul 6, 2007 James Walker may have said:

>Would anyone object if I removed the corresponding binary project files 
>(.mcp)?  I don't want to bother to update them, and I worry that these 
>old project files might confuse someone who downloads Quesa.  The only 
>down side I see is that we lose the cvs history.

You might try bringing the project over to svn on SF. I'm not sure if it
brings over the history or not, as I haven't had time to do this on my
projects. But, if it does, then you could delete the binary files and
the history would remain in svn.

Overall, switching to svn has been a huge gain on the projects where I
have done it, so it's probably worth doing for Quesa in any case.

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________ 
If progress means moving forward, what does congress mean?

Time to trash DrawRegions?

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

Is anyone using any plug-in renderers that need draw region support?  If 
not, I'd like to get rid of draw regions and simplify some of the draw 
context code.

Here's an excerpt from an old posting that explains what draw regions 
are about.


On 4/27/2000, Dair Grant wrote:

> OK, for the rest of the list, here's a quick overview of what a draw
> region is (you typically only see them when writing a renderer):
> 
> A "draw context" is the QD3D object associated with the native windowing
> system - you've got a Mac draw context that takes a WindowPtr, a Windows
> draw context that takes an HDC, etc.
> 
> A "draw region" is a lower-level object, which was historically needed
> to support RAVE.
> 
> A draw context can span multiple monitors (since WindowPtrs can), but
> since RAVE engines are attached to a single monitor you need some way to
> break down a high level window spanning multiple monitors into the
> monitor-specific areas that the output should be sent to.
> 
> 
> So, an example: when rendering to a window that straddles an 16 bit
> monitor and a 32 bit monitor, there's one draw context (that holds the
> WindowPtr) and _two_ draw regions (one for the 16 bit monitor and one
> for the 32 bit monitor).
> 
> To render to this window using RAVE, the IR needs to build two RAVE data
> structures - one for each monitor.
> 
> And to create them, it needs to know the depths, row-bytes, resolution,
> etc of the two monitors - as well as things like the offsets within the
> frame buffer to the pixels that correspond to the exposed window area,
> and any clipping mask that needs to be applied to prevent output from
> overwriting other windows on the screen.
> 
> And to get all this low-level information, it uses (we got there
> eventually!) the two draw regions...
> 
> So whenever a draw context is created/updated, a list of draw regions is
> also maintained - each of these draw regions holds all the low-level
> information needed to render to this draw context using something like
> RAVE.
> 
> 
>> Why I've to move away from draw regions?
> 
> Their main purpose is to allow you to support multiple monitors on top
> of a hardware acceleration API that drives a single monitor at a time
> (e.g., RAVE).
> 
> If you're using an API like OpenGL, there's no need - you just pass down
> the WindowPtr, and let Apple take care of making OpenGL support multiple
> monitors.
> 
> So, I think we definitely want to get away from draw regions if we can.

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

Re: Wireframe Renderer

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

Jose' Cruanyes wrote:
> Made the wireframe renderer derived from the OpenGL one, in order to  
> semplify the maintenaince.
> 
> I've changed the projects for xCode, and soon those for VisualStudio,  
> unfortunately I can't update the projects for Codewarrior, so if  
> someone can remove:
> 
> WFRenderer.c
> WFRegister.c
> WFUpdate.c
> WFGeometry.c
> WFPrefix.h
> WFUpdate.h
> WFGeometry.h
> WFRegister.h
> 
> and add
> WFRenderer.cpp
> 

I've updated the XML project files (.mcp.xml) for Mac and Windows.

Would anyone object if I removed the corresponding binary project files 
(.mcp)?  I don't want to bother to update them, and I worry that these 
old project files might confuse someone who downloads Quesa.  The only 
down side I see is that we lose the cvs history.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Alpha channel in RayShade

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

On 6 Jul, 2007, at 17:26, Jose' Cruanyes wrote:

>
> no idea... :(
> just to assert the obvious: are you sure you have not another plug-in
> laying around?
>

I have run it under the debugger and seen that options.maxDepth was  
1200, and still it ran at the normal speed.

I have done the changes to output the alpha channel. I preserved the  
code which does the gamma correction, but it does not seem to be  
possible that it is even not one. On Mac, the O.S. does the gamma  
correction for you, I don't know about Windows. Is this ever likely  
to be used?

I have six amended files for the alpha channel fix. Three or four are  
single lines but one is extensive. How would you like to handle  
checking this in?

Roger.

Re: Alpha channel in RayShade

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

Il giorno 06/lug/07, alle ore 17:35, Roger Holmes ha scritto:

> We changed to 8, then 12 then 1200, each time cleaning all and
> rebuilding, and it has made no difference to either the rendering
> time or the speckles.
>

no idea... :(
just to assert the obvious: are you sure you have not another plug-in =20=

laying around?

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: Alpha channel in RayShade

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

On 6 Jul, 2007, at 14:11, Jose' Cruanyes wrote:

>
> No, this problem is another, it stops a recursion too early...
> to solve it go to line 242 of file RTInterface/RT.cpp
> and change
>
> Options.maxdepth = MAXDEPTH;
>
> to something bigger (MAXDEPTH is defined as 5) like 8
>
> please note that for every unit added the render time is doubled
>
> We're working on those files... expect the first batch of changes
> this evening, so don't work too heavy on this...


We changed to 8, then 12 then 1200, each time cleaning all and  
rebuilding, and it has made no difference to either the rendering  
time or the speckles.

Roger.

Modifications to rayshade

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

in RT.cpp  we've added a procedure (called rt_tweak)where touch the =20
parameters, shortly there we will control part of these parameters =20
via renderer properties.

Also, we've added support for spherical lights, to test them, change =20
the last parameter in line 383 of file RSRegister to a value like the =20=

radius of your light (test an scaled value of about 10cm)




Pax et Bonum

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

Wireframe Renderer

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

Made the wireframe renderer derived from the OpenGL one, in order to =20
semplify the maintenaince.

I've changed the projects for xCode, and soon those for VisualStudio, =20=

unfortunately I can't update the projects for Codewarrior, so if =20
someone can remove:

WFRenderer.c
WFRegister.c
WFUpdate.c
WFGeometry.c
WFPrefix.h
WFUpdate.h
WFGeometry.h
WFRegister.h

and add
WFRenderer.cpp

=09


We have also added properties to control the line width and the color =20=

of both the hiddenline and the WireFrame renderers,
here're the docs:

kQ3RendererPropertyLineWidth
		Line width to be used in wire frame and hidden line =
renderers.
		Data type: TQ3Float32.
		Default value: 1.0.
			=09
kQ3RendererPropertyUseColor
		in the Hiddenline Renderer - Whether the renderer has to =
fill color
			the geometries or leave them white.
		in the WireFrame Renderer - if the lines should follow =
the geometry =20
color
  		   or draw them black
  		data type: TQ3Boolean.  Default value: kQ3True.


We've also updated the hiddenline renderer


Pax et Bonum

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