quesa-develop — Mailing list for Quesa development

Re: FYI - quesa.org has old email info

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

On Aug 2, 2004, at 8:35 AM, Lars Jensen wrote:

> I was introducing someone to Quesa today, sending them to 
> "www.quesa.org",
> and I noticed that that page still refers to designcommunity rather 
> than
> sourceforge for email.

There's lots of old stuff there.  Send people to quesa.sourceforge.net 
instead.  I believe the plan is to redirect the quesa.org domain there, 
but obviously it hasn't happened yet.
--
<http://www.jwwalker.com/>

FYI - quesa.org has old email info

[Lars J. <lar...@rc...>]

I was introducing someone to Quesa today, sending them to "www.quesa.org",
and I noticed that that page still refers to designcommunity rather than
sourceforge for email.

lj

Re: Bug in E3Triangle_InterpolateHit

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

On Thursday, July 29, 2004, at 09:56  pm, Dair Grant wrote:

> Roger Holmes wrote:
>
>> There is a bug in E3Triangle_InterpolateHit when it is asked to return
>> a normal vector.
>>
>> It should return a normal in world coordinates, and if there are no
>> normals in the attribute set of the surface, nor in the attribute sets
>> of the vertices then all is well.
>
> A normal is a vector, so it doesn't have a coordinate system as such.
> But I see what you mean, the normal is from the surface before it was
> transformed to world coordinates or after the transform.

Yes, its a sort of floating coordinate system, it does not have an 
origin
but it does have directions for its axes.



> The docs for QD3D say the result here is:
>
>     The surface normal of the picked object at the point of
>     intersection with the pick geometry.
>
> Are the docs incorrect? I.e., what happened under QD3D was actually:
>
>     ...with the pick geometry, transformed by the local->world matrix.

I looked in the blue book and can see no description of the normal.
As you say, QD3D certainly transformed it by the local->world matrix
and hence so should we. We can clarify it in our own documentation
and maybe we should warn our users just in case their programs
are only happening to see the broken version, and hence will break
when we fix the broken case to be the same as the unbroken case.

I don't think many people use picking at present so I think it is best
that we fix it before it becomes more popular. If it worked properly
that might make it more popular too.



> At the moment we do have a problem in that we're being inconsistent
> (we're returning the supplied normal as-is if it exists, but will
> calculate a normal from a transformed triangle if not), but which is 
> the
> correct way to adjust the results?

Am I being simple in thinking that multiplying by localToWorld will do 
the trick?
Probably, the rotational component is fine but will non uniform scaling 
in
X,Y & Z and shearing mess things up? Come to think of it I think I had 
to
write some special code in my renderer for transforming normals.
I will have a look before I write any more.

OK. In my UpdatePipeline routine I calculate  a localToWorldForNormals
matrix. I set it to the localToWorld, then set the bottom row to 
0,0,0,1 and then
set it to the inverse of its transpose. A comment refers to 'Computer
Graphics principals and practice' page 1108.

So I guess that's it, but it is a heavy bit of calculation. Should we 
be doing it
when we get a 'hit' or every time we change localToWorld? I guess there
are typically not many hits, and it would be easier to put the code in 
the
existing routine. Or is this matrix calculated somewhere already?

>
> Should the normal always be of the surface in its own coordinate 
> system,
> or taken after the surface has been transformed?
>
> The surface point is always returned in world coordinates, so it does
> sound plausible that the normal should be from the transformed surface
> too.
>
>
>> I have fixed this in my version of Quesa by passing the view into
>> E3Triangle_InterpolateHit and then calling Q3Vector3D_Transform where
>> appropriate. I also have to include E3View.h in E3Utils.c so I can get
>> the transform using E3View_State_GetLocalToWorld.
>>
>> Is this OK? Should I pass in the matrix instead? Should it return a
>> flag to say if the normal is in world or local coordinates and then
>> fix it in the calling code (2 places)? Should it pick it up in some
>> other way?
>
> Best approach would be to pass in the view I think, as that's also
> passed in to the next routine in line (E3Pick_RecordHit as it also 
> needs
> to record the local->world matrix if the caller wants that info back).

Good.

>
> I wouldn't try and stash an extra flag somewhere, we should just 
> mandate
> that the normal that comes out of here is consistent with the thing 
> that
> E3Pick_RecordHit will save for the app (so either before or after the
> transform, but always the same, depending on what QD3D did).

OK

>
>
>> Also, when the normal is calculated from three vertex normals, it can
>> result in a normal which is not normalised. Is there any good reason
>> for this or can I normalise it?
>
> The normal is normalised by e3pick_hit_initialise - we defer doing the
> normalisation until we know that the caller really does want that bit 
> of
> info back.
>

Oh good, I can take it out of my version of Quesa then.

> -dair
> ___________________________________________________
> mailto:dair+refnum.com       http://www.refnum.com/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source 
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Texture quality Low

[Dair G. <da...@re...>]

Daniele Cavallini wrote:

>With Q3InteractiveRenderer_SetRAVETextureFilter Quesa work well. There
>is a problem with rayshade when I use texture. The texture in shadow
>are black. You can see a screenshot at link:

Hmm, I seem to recall there is a bug logged for Rayshade and textures
already - I think the UVs aren't being passed on correctly (or perhaps
the wrap/repeat mode).

If you can't see it, can you log another bug and attach those images?


>I modified  function
>E3WindowsSystem_LoadPlugins(void)
=2E..
>I think  it is useful load plugin in current directory.

Yes, that sounds like a good idea - I've checked it in.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Bug in E3Triangle_InterpolateHit

[Dair G. <da...@re...>]

Roger Holmes wrote:

>There is a bug in E3Triangle_InterpolateHit when it is asked to return
>a normal vector.
>
>It should return a normal in world coordinates, and if there are no
>normals in the attribute set of the surface, nor in the attribute sets
>of the vertices then all is well.

A normal is a vector, so it doesn't have a coordinate system as such.
But I see what you mean, the normal is from the surface before it was
transformed to world coordinates or after the transform.


The docs for QD3D say the result here is:

    The surface normal of the picked object at the point of
    intersection with the pick geometry.

Are the docs incorrect? I.e., what happened under QD3D was actually:

    ...with the pick geometry, transformed by the local->world matrix.

At the moment we do have a problem in that we're being inconsistent
(we're returning the supplied normal as-is if it exists, but will
calculate a normal from a transformed triangle if not), but which is the
correct way to adjust the results?

Should the normal always be of the surface in its own coordinate system,
or taken after the surface has been transformed?

The surface point is always returned in world coordinates, so it does
sound plausible that the normal should be from the transformed surface
too.


>I have fixed this in my version of Quesa by passing the view into
>E3Triangle_InterpolateHit and then calling Q3Vector3D_Transform where
>appropriate. I also have to include E3View.h in E3Utils.c so I can get
>the transform using E3View_State_GetLocalToWorld.
>
>Is this OK? Should I pass in the matrix instead? Should it return a
>flag to say if the normal is in world or local coordinates and then
>fix it in the calling code (2 places)? Should it pick it up in some
>other way?

Best approach would be to pass in the view I think, as that's also
passed in to the next routine in line (E3Pick_RecordHit as it also needs
to record the local->world matrix if the caller wants that info back).

I wouldn't try and stash an extra flag somewhere, we should just mandate
that the normal that comes out of here is consistent with the thing that
E3Pick_RecordHit will save for the app (so either before or after the
transform, but always the same, depending on what QD3D did).


>Also, when the normal is calculated from three vertex normals, it can
>result in a normal which is not normalised. Is there any good reason
>for this or can I normalise it?

The normal is normalised by e3pick_hit_initialise - we defer doing the
normalisation until we know that the caller really does want that bit of
info back.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Bug in E3Triangle_InterpolateHit

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

There is a bug in E3Triangle_InterpolateHit when it is asked to return 
a normal vector.

It should return a normal in world coordinates, and if there are no 
normals in the
attribute set of the surface, nor in the attribute sets of the vertices 
then all is well.

When there are normals then it takes these (which are in local 
coordinates) and
does some averaging of them and then returns them as if they were in 
world
coordinates.

I have fixed this in my version of Quesa by passing the view into 
E3Triangle_InterpolateHit
and then calling Q3Vector3D_Transform where appropriate. I also have to 
include E3View.h
in E3Utils.c so I can get the transform using 
E3View_State_GetLocalToWorld.

Is this OK?
Should I pass in the matrix instead?
Should it return a flag to say if the normal is in world or local 
coordinates and then
fix it in the calling code (2 places)?
Should it pick it up in some other way?


Also, when the normal is calculated from three vertex normals, it can 
result in a
normal which is not normalised. Is there any good reason for this or 
can I
normalise it?

Roger.

Re: Texture quality Low

[Daniele C. <dca...@in...>]

With Q3InteractiveRenderer_SetRAVETextureFilter Quesa work well.
There is a problem with rayshade when I use texture. The texture in shadow 
are black. You can see a screenshot at link:
Render Quesa:
http://www.interstudio.net/quesa/TextureQuesa.JPG
Render Rayshade:
http://www.interstudio.net/quesa/TextureRayshade.JPG


I modified  function
E3WindowsSystem_LoadPlugins(void)
{       TCHAR systemDir[MAX_PATH];

         // Register Quesa plug-ins
         if(GetCurrentDirectory(MAX_PATH * sizeof(*systemDir),systemDir))
                 e3windowsystem_loadplugins(systemDir, TEXT("xq3"));

         if(GetSystemDirectory(systemDir, MAX_PATH * sizeof(*systemDir)) > 0)
                 e3windowsystem_loadplugins(systemDir, TEXT("xq3"));
         if(GetWindowsDirectory(systemDir, MAX_PATH * sizeof(*systemDir)) > 0)
                 e3windowsystem_loadplugins(systemDir, TEXT("xq3"));
}
I think  it is useful load plugin in current directory.


At 19.20 28/07/04, you wrote:
>On 28-Jul-04, at 9:06 AM, Daniele Cavallini wrote:
>
>>This is a screenshot about old and new quesa (high old quesa and  low new 
>>quesa). The problem are same in windows 98/XP and Mac Os X and it is not 
>>depending  from dimension of image.  I don't call 
>>Q3InteractiveRenderer_SetRAVETextureFilter I  will try to call it.
>
>Set Q3InteractiveRenderer_SetRAVETextureFilter to kQATextureFilter_Fast to 
>get the old pixelated look, or (better yet) use MipMap textures with 
>UseMipMapping set to false instead of PixMaps.
>
>What you're seeing is mipmap filtering, which is actually considered 
>_higher_ quality since it reduces pixel crawling and moire artifacts. The 
>default filter setting (kQATextureFilter_Mid) uses bilinear filtered 
>mipmaps, which have a tendency to blur as the image size is reduced. 
>kQATextureFilter_Best will provide better results, but you will still see 
>some blurring.
>
>The best of both worlds can be had by using anisotropic filtering. I'm 
>considering adding this to a custom Quesa build via the Set/GetProperty 
>API for my own purposes, but I'll gladly share the code with anyone interested.
>
>Frank.
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Queeg QGTriMesh copy ctor dups shader?

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

Keith Wiley <kw...@cs...> wrote:

>Should either of these two approaches render faster?

I don't think there would be a significant difference.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Queeg QGTriMesh copy ctor dups shader?

[Keith W. <kw...@cs...>]

On Wed, 28 Jul 2004, James W. Walker wrote:

> If the objects are supposed to look the same except for translation,
> scale, and rotation, then I don't see why you'd want to duplicate the
> geometry either.  Just have some group objects containing different
> transformation objects but references to the same geometry objects.

Oh wow.  Cool.  Hmmm, I know almost nothing about group objects presently.
I'll see what the QD3D manual has to say.

Should either of these two approaches render faster?

________________________________________________________________________
Keith Wiley                                kw...@cs...
http://www.unm.edu/~keithw                 http://www.mp3.com/KeithWiley

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Queeg QGTriMesh copy ctor dups shader?

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

Keith Wiley <kw...@cs...> wrote:

>Okay, so if a want a large number objects made from the same model (which
>then differ by translation, scale, and rotation), then this approach is
>wrong?  I shouldn't create one base object and clone its trimesh this way,
>because you're saying I get gobs of identical shaders and textures.  Is
>that right?

Right.

>So what I need to do is manually duplicate the geometry of the trimesh and
>manually set each trimesh to use the exact same shader object, right?

If the objects are supposed to look the same except for translation, 
scale, and rotation, then I don't see why you'd want to duplicate the 
geometry either.  Just have some group objects containing different 
transformation objects but references to the same geometry objects.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Queeg QGTriMesh copy ctor dups shader?

[Keith W. <kw...@cs...>]

On Wed, 28 Jul 2004, James W. Walker wrote:

> Duplicating Quesa objects is recursive.  When you duplicate an
> attribute set, you duplicate the shader attribute it contains, and
> you duplicate the texture object that contains.

Okay, so if a want a large number objects made from the same model (which
then differ by translation, scale, and rotation), then this approach is
wrong?  I shouldn't create one base object and clone its trimesh this way,
because you're saying I get gobs of identical shaders and textures.  Is
that right?

So what I need to do is manually duplicate the geometry of the trimesh and
manually set each trimesh to use the exact same shader object, right?

________________________________________________________________________
Keith Wiley                                kw...@cs...
http://www.unm.edu/~keithw                 http://www.mp3.com/KeithWiley

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Queeg QGTriMesh copy ctor dups shader?

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

Keith Wiley <kw...@cs...> wrote:

>The QD3D manual says that if the new object of Q3Object_Duplicate is a
>shared object, then is ref count is set to one.  Now, Q3Object_Duplicate
>is being called on the TriMesh.triMeshAttributeSet, not the shader per se.
>I assume shaders are shared, but I assume that trimesh attributes sets are
>not, so I'm unclear as to whether duplicating a trimesh a zillion times
>fills RAM up with countless copies of an identical shader and a fairly
>sizable texture bitmap...which is obviously not what I want.

Duplicating Quesa objects is recursive.  When you duplicate an 
attribute set, you duplicate the shader attribute it contains, and 
you duplicate the texture object that contains.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Queeg QGTriMesh copy ctor dups shader?

[Keith W. <kw...@cs...>]

I am trying to figure out if the Queeg QGTriMesh copy ctor duplicates
shader objects, or just references to a single shader?  It has this line:

mTriMeshData.triMeshAttributeSet = Q3Object_Duplicate(
srcData.triMeshAttributeSet );

The QD3D manual says that if the new object of Q3Object_Duplicate is a
shared object, then is ref count is set to one.  Now, Q3Object_Duplicate
is being called on the TriMesh.triMeshAttributeSet, not the shader per se.
I assume shaders are shared, but I assume that trimesh attributes sets are
not, so I'm unclear as to whether duplicating a trimesh a zillion times
fills RAM up with countless copies of an identical shader and a fairly
sizable texture bitmap...which is obviously not what I want.

________________________________________________________________________
Keith Wiley                                kw...@cs...
http://www.unm.edu/~keithw                 http://www.mp3.com/KeithWiley

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Texture quality Low

[Frank C <li...@si...>]

On 28-Jul-04, at 9:06 AM, Daniele Cavallini wrote:

> This is a screenshot about old and new quesa (high old quesa and  low 
> new quesa). The problem are same in windows 98/XP and Mac Os X and it 
> is not depending  from dimension of image.  I don't call 
> Q3InteractiveRenderer_SetRAVETextureFilter I  will try to call it.

Set Q3InteractiveRenderer_SetRAVETextureFilter to kQATextureFilter_Fast 
to get the old pixelated look, or (better yet) use MipMap textures with 
UseMipMapping set to false instead of PixMaps.

What you're seeing is mipmap filtering, which is actually considered 
_higher_ quality since it reduces pixel crawling and moire artifacts. 
The default filter setting (kQATextureFilter_Mid) uses bilinear 
filtered mipmaps, which have a tendency to blur as the image size is 
reduced. kQATextureFilter_Best will provide better results, but you 
will still see some blurring.

The best of both worlds can be had by using anisotropic filtering. I'm 
considering adding this to a custom Quesa build via the Set/GetProperty 
API for my own purposes, but I'll gladly share the code with anyone 
interested.

Frank.

Re: Texture quality Low

[Daniele C. <dca...@in...>]

You can see some screenshoots with the old and new textures display.

Image1 obtained with quesa 1.6d19
http://www.interstudio.net/quesa/TexturesQuesaNew1.jpg

Image1 obtained with quesa 1.6d18
http://www.interstudio.net/quesa/TexturesQuesaOld1.jpg


Image2 obtained with quesa 1.6d19
http://www.interstudio.net/quesa/TexturesQuesaNew2.jpg

Image2 obtained with quesa 1.6d18
http://www.interstudio.net/quesa/TexturesQuesaOld2.jpg

The dimension of texture is 192x192 pixel and Operating system used is MAC OS X panther



At 11.39 28/07/04, you wrote:
>Daniele Cavallini wrote:
>
>>In the last Quesa version the render texture's quality is not high.
>>Can I set the quality? Is possible obtain best quality?
>
>Can you post a screenshot somewhere demonstrating what you mean, and
>some more details about the texture (dimensions, pixel format, etc).
>
>If you're not calling it already, you may want to call:
>
>  Q3InteractiveRenderer_SetRAVETextureFilter
>
>To request some filtering on the texture.
>
>
>-dair
>___________________________________________________
>mailto:dair+refnum.com       http://www.refnum.com/
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idG21&alloc_id040&opick
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Texture quality Low

[Daniele C. <dca...@in...>]

This is a screenshot about old and new quesa (high old quesa and  low new 
quesa). The problem are same in windows 98/XP and Mac Os X and it is not 
depending  from dimension of image.  I don't call 
Q3InteractiveRenderer_SetRAVETextureFilter I  will try to call it.
Daniele
At 11.39 28/07/04, you wrote:
>Daniele Cavallini wrote:
>
> >In the last Quesa version the render texture's quality is not high.
> >Can I set the quality? Is possible obtain best quality?
>
>Can you post a screenshot somewhere demonstrating what you mean, and
>some more details about the texture (dimensions, pixel format, etc).
>
>If you're not calling it already, you may want to call:
>
>   Q3InteractiveRenderer_SetRAVETextureFilter
>
>To request some filtering on the texture.
>
>
>-dair
>___________________________________________________
>mailto:dair+refnum.com       http://www.refnum.com/
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idG21&alloc_id040&opick
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Texture quality Low

[Dair G. <da...@re...>]

Daniele Cavallini wrote:

>In the last Quesa version the render texture's quality is not high.
>Can I set the quality? Is possible obtain best quality?

Can you post a screenshot somewhere demonstrating what you mean, and
some more details about the texture (dimensions, pixel format, etc).

If you're not calling it already, you may want to call:

  Q3InteractiveRenderer_SetRAVETextureFilter

To request some filtering on the texture.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Texture quality Low

[Daniele C. <dca...@in...>]

In the last Quesa version the render texture's quality is not high. Can I 
set the quality? Is possible obtain best quality?
Daniele

Re: Problem to compile in windows

[Dair G. <da...@re...>]

Daniele Cavallini wrote:

>I have create a New Project I copy and paste file dsp in the new file
>and now work fine. Thank's a lot. Is Possible compile QuesaViewer in a
>Windows Platform? I try to compile but there are a lot of error caused
>Macintosh setting. Perhaps I must write some #define ...

I don't know if the unified viewer (there were separate Windows and Mac
viewer APIs under QD3D, and we introduced a cross-platform API to
replace it) was finished off for Windows actually, so you may get a
build error if you try and build that part.

However the main library should build correctly, and you should be able
to build something like GeomTest to confirm it works.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: reasonable field of view?

[Keith W. <kw...@cs...>]

Frank C wrote:

> Quesa's fov always affects the smallest aspect of the viewport, so 
> "normal circumstances" in this case means if your 3D window is wider 
> than it is tall (usually the case for games), the fov is the maximum 
> view angle of the vertical aspect.
>
> In Quake, if you have a fov of 90 and your screen has a 3:4 aspect 
> ratio, the vertical fov is actually 3/4*90 (67.5) which is why 70 
> degrees looks just about right for a Quesa view with the same aspect, 
> since it gives you a horizontal fov of 4/3*70 - about 93 degrees.

Yep.  Thanks.

________________________________________________________________________
Keith Wiley                                kw...@cs...
http://www.unm.edu/~keithw                 http://www.mp3.com/KeithWiley

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: Problem to compile in windows

[Daniele C. <dca...@in...>]

I have create a New Project I copy and paste file dsp in the new file and 
now work fine. Thank's a lot.
Is Possible compile QuesaViewer in a Windows Platform? I try to compile but 
there are a lot of error caused Macintosh setting. Perhaps I must write 
some #define ...
Daniele

At 15.44 27/07/04, you wrote:
>Daniele Cavallini wrote:
>
> >I try to compile the last version of quesa with visual studio 6.0 in
> >windows but I fail. I don't succeed open the file .dsw or .dsp. Someone
> >have compiled quesa with windows? Can help me?
> >thank's a lot
>
>Do you get an error message when opening the project at all?
>
>The VC project files are text files, so it'd be worth opening them in a
>text editor and making sure the contents look plausible and that they've
>been fetched with DOS line endings.
>
>
>-dair
>___________________________________________________
>mailto:dair+refnum.com      http://www.refnum.com/
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idG21&alloc_id040&opick
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Problem to compile in windows

[Dair G. <da...@re...>]

Daniele Cavallini wrote:

>I try to compile the last version of quesa with visual studio 6.0 in=20
>windows but I fail. I don't succeed open the file .dsw or .dsp. Someone=20
>have compiled quesa with windows? Can help me?
>thank's a lot=20

Do you get an error message when opening the project at all?

The VC project files are text files, so it'd be worth opening them in a
text editor and making sure the contents look plausible and that they've
been fetched with DOS line endings.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Problem to compile in windows

[Daniele C. <dca...@in...>]

I try to compile the last version of quesa with visual studio 6.0 in 
windows but I fail. I don't succeed open the file .dsw or .dsp. Someone 
have compiled quesa with windows? Can help me?
thank's a lot 

Re: reasonable field of view?

[Frank C <li...@si...>]

On 26-Jul-04, at 9:22 PM, Keith Wiley wrote:

> Frank C wrote:
>
>> On 26-Jul-04, at 5:57 PM, Keith Wiley wrote:
>>
>>> What is the generic field of view of all the various first-person 
>>> computer
>>> games?  My own sloppy experimentation suggests that my binocular 
>>> field
>>> (bounded by the bridge of my nose) is around 70 degrees...
>>
>>
>> Most FPS games default to around 90 degrees of horizontal FOV - but 
>> under normal circumstances Quesa's uses vertical FOV, so 65-70 sounds 
>> about right.
>
> Hmmm, well that does it make it a little more interesting.  So you're 
> saying the camera fov attribute governs the vertical fov, not the 
> horizontal?  That wasn't my initial expectation.  What do you mean by 
> "normal circumstances"?  Can it be either depending on the details?

Quesa's fov always affects the smallest aspect of the viewport, so 
"normal circumstances" in this case means if your 3D window is wider 
than it is tall (usually the case for games), the fov is the maximum 
view angle of the vertical aspect.

In Quake, if you have a fov of 90 and your screen has a 3:4 aspect 
ratio, the vertical fov is actually 3/4*90 (67.5) which is why 70 
degrees looks just about right for a Quesa view with the same aspect, 
since it gives you a horizontal fov of 4/3*70 - about 93 degrees.

Hope that makes sense!
Frank.

Re: reasonable field of view?

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

Keith Wiley <kw...@cs...> wrote:

>So you're saying the camera fov attribute governs the vertical fov,
>not the horizontal?  That wasn't my initial expectation.  What do
>you mean by "normal circumstances"?  Can it be either depending on
>the details?

RTFM.  If you look up angle aspect cameras in the QD3D manual, the 
discussion of fov says

"If the value in the aspectRatioXToY field is greater than 1.0, the 
field of view is vertical; if the value in the aspectRatioXToY field 
is less than 1.0, the field of view is horizontal."

Hmm, speaking of docs, the comments on TQ3ViewAngleAspectCameraData 
in QuesaCamera.h are a bit unclear on this.  I think I'll change it.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>