quesa-develop — Mailing list for Quesa development

Re: Quesa under linux 64bit

[<lo...@ma...>]

On 21 f=E9vr. 06, at 05:04, James W. Walker wrote:

>
> On Feb 20, 2006, at 6:50 PM, lo=EFc s=E9galou wrote:
>
>> I just add the cast (uintptr_t) before the cachedTexture. (need to =20=

>> add #include <stdint.h>)
>
> Do you mean like (GLuint) (uintptr_t) cachedTexture ?

Yes.

>
>> PS : do I need to commit the modification ?
>
> Can you?  I thought only project administrators had CVS commit =20
> privileges.

Oops you right I can't do it.

-- lo=EFc

Re: Quesa under linux 64bit

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

On Feb 20, 2006, at 6:50 PM, lo=EFc s=E9galou wrote:

> I just add the cast (uintptr_t) before the cachedTexture. (need to =20
> add #include <stdint.h>)

Do you mean like (GLuint) (uintptr_t) cachedTexture ?

> PS : do I need to commit the modification ?

Can you?  I thought only project administrators had CVS commit =20
privileges.

I would consider this a temporary fix.  It is conceivable, though =20
probably extremely unlikely, for two pointers to convert to the same =20
GLuint.=

Re: Quesa under linux 64bit

[<lo...@ma...>]

On 21 f=E9vr. 06, at 03:04, lo=EFc s=E9galou wrote:
> Method but it's the same thing here. doing an error with GCC 4.0.1

I just add the cast (uintptr_t) before the cachedTexture. (need to =20
add #include <stdint.h>)

I found more information about 64 bit pointer inside the AMD =20
documentation :

http://www.amd.com/us-en/assets/content_type/DownloadableAssets/=20
AMD64_Porting_Guide_Final_Jul03.pdf


-- lo=EFc

PS : do I need to commit the modification ?

Re: Quesa under linux 64bit

[<lo...@ma...>]

On 21 f=E9vr. 06, at 02:42, James W. Walker wrote:
>
> There are two ways to approach this, the easy way and the hard =20
> way.  The easy way would be to find a way to make the compiler stop =20=

> complaining.  Actually, I am surprised that it is an error rather =20
> than a warning.  What happens if you use reinterpret_cast instead =20
> of a C-style cast?

I've tried with reinterpret_cast method but it's the same thing here. =20=

doing an error with GCC 4.0.1

I'll keep you inform if I find a solution

thanks,

-- lo=EFc

Re: Quesa under linux 64bit

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

On Feb 20, 2006, at 4:56 PM, lo=EFc s=E9galou wrote:

> Hello the Quesa Team,
>
> I have some trouble to compile Quesa under Linux (Mandriva 2006 - =20
> AMD 64bit) :
>
> ./Source/Renderers/Interactive/IRTexture.c: In function 'TQ3Status =20
> ir_texture_load(TQ3CachedTexture*)':
> ./Source/Renderers/Interactive/IRTexture.c:526: error: cast from =20
> 'TQ3CachedTexture*' to 'GLuint' loses precision
> ./Source/Renderers/Interactive/IRTexture.c: In function 'TQ3Status =20
> IRRenderer_Texture_Set(OpaqueTQ3Object*, TQ3InteractiveData*, =20
> OpaqueTQ3Object*, OpaqueTQ3Object*)':
> ./Source/Renderers/Interactive/IRTexture.c:863: error: cast from =20
> 'TQ3CachedTexture*' to 'GLuint' loses precision
>
>
> (using version from CVS)
>
> Any idea how to solve this problem ?


There are two ways to approach this, the easy way and the hard way.  =20
The easy way would be to find a way to make the compiler stop =20
complaining.  Actually, I am surprised that it is an error rather =20
than a warning.  What happens if you use reinterpret_cast instead of =20
a C-style cast?

The harder way would be for us to stop using a pointer as an OpenGL =20
texture name.  Instead perhaps we could use glGenTextures, and add =20
that field to the TQ3CachedTexture structure.=

Quesa under linux 64bit

[<lo...@ma...>]

Hello the Quesa Team,

I have some trouble to compile Quesa under Linux (Mandriva 2006 - AMD =20=

64bit) :

./Source/Renderers/Interactive/IRTexture.c: In function 'TQ3Status =20
ir_texture_load(TQ3CachedTexture*)':
./Source/Renderers/Interactive/IRTexture.c:526: error: cast from =20
'TQ3CachedTexture*' to 'GLuint' loses precision
./Source/Renderers/Interactive/IRTexture.c: In function 'TQ3Status =20
IRRenderer_Texture_Set(OpaqueTQ3Object*, TQ3InteractiveData*, =20
OpaqueTQ3Object*, OpaqueTQ3Object*)':
./Source/Renderers/Interactive/IRTexture.c:863: error: cast from =20
'TQ3CachedTexture*' to 'GLuint' loses precision


(using version from CVS)

Any idea how to solve this problem ?

Thanks,

-- lo=EFc

add line feed

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

When you release a new version  of quesa is possible add line feed 
into all file?
This because in windows there are some problem. I must open all file, 
modify and save again.
A newbie  maybe don't succeed to open the windows project and least 
of all to compile.

Thanks

Re: Quesa on Intel Macs!

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

Hi Sean and all,

We also have success with Quesa running in Intel, though the
rest of the application and its plugins still need work.

We can drag and drop into the Intel version from the released
version running under Rosetta, no problems with byte swapping,
though we have not yet tried textures.

I am hoping there will not be any problems with reading and
writing files as Quesa has been working on Windows for some
time.



Roger Holmes.



On 17 Jan, 2006, at 22:11, Sean McBride wrote:

> Hi all,
>
> So have many of you tried Quesa on Intel Macs?
>
> I've been using it on a DTK for several months, and its working =20
> very nicely!
>
> In our app, there are a few byte swapped images, it may be our bug or
> Quesa's bug.  Before digging deeper, I thought I'd ask here if other
> people have tried it out at all.
>
> Thanks,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 se...@ro...
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr=E9al, Qu=E9bec, Canada
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642=

> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Quesa on Intel Macs!

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

Hi all,

So have many of you tried Quesa on Intel Macs=3F

I've been using it on a DTK for several months, and its working very nicely!

In our app, there are a few byte swapped images, it may be our bug or
Quesa's bug.  Before digging deeper, I thought I'd ask here if other
people have tried it out at all.

Thanks,

-- 
=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: Poser 3DMFs and Quesa-RealBasic

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

Hi,

Some of my company's customers used to import 3DMF from Poser into our
products back in the days of QuickDraw3D. We have done some testing and
found that recent versions of Poser produce files purporting to be  
3DMF, but
which can not be read either by our OS-X products using Quesa or even by
our original OS-9 products using QuickDraw3D. Maybe we were just unlucky
with the particular files we tested, maybe some files do work. When  
tested
with the older versions of Poser, we could import its files into any  
of our
products, including the OS-X ones using Quesa. I believe the fault  
lies in
Poser, but their technical support people seem disinterested and suggest
we use 3DS (which lacked any texture data when we tried it). They then
suggested another format, the name escapes me and my emails from
that week got wiped from my machine. I understand (from a third party
who downloaded a demo version of the very latest version) that there
was no 3DMF support. Of course it might be they have no 3DMF export
in a demo version, but perhaps do in the issued product. Personally I
hope that I get a pleasant surprise when they fix it, but it looks  
unlikely.

Roger Holmes.


On 26 Dec, 2005, at 17:46, Don Bice wrote:

> Hello,
>
> When I export a 3dmf from poser 6, rb crashes when trying to open  
> it. I
> have the latest update for poser.
>
> Anyone know what the deal is with poser 3dmfs?
>
> If I export a .lwo 3d object from Poser, my other 3d program Cararra
> can open it and then save it as a 3dmf. These 3dmfs from Cararra work
> fine in rb. The bad news is that in the process, a 100k 3dmf (when
> poser exports it) turns into a 1mb 3dmf when Cararra exports it. So,
> this becomes an issue when having a lot of objects/shapes in rb3d
> spaces.
>
> Another issue with poser is that if an object has a texture, (like
> pants or a custom face) the texture gets lost when opening it in
> Cararra (ive tried every 3d format).
>
>
> I think all these issues would go away if Poser 3dmfs didnt make rb
> crash. But, I realize this is probably Poser's fault and not quesa's
> fault, but this is a serious bummer. Does anyone have any insight in
> this?
>
> Thanks.
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today -  
> it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/ 
> direct/01/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: 3DMF export

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

On Dec 28, 2005, at 1:09 AM, Edward K. Chew wrote:

> That sort of makes it difficult to open a file without calling on  
> deprecated APIs, doesn't it?

True.

> I guess you can turn an FSRef into a path and go that route, but  
> paths aren't without problems either, from what I've heard.

Yes, there is the 1024-character limit on path length.

>   I think I'll go back to using FSSpecs for now...

Another option would be to write the 3DMF data to a memory storage  
object, and then copy the memory to a file using FSRef APIs.

Re: 3DMF export

[Edward K. C. <ek...@lg...>]

On Dec 28, 2005, at 12:14 AM, James W. Walker wrote:

> I believe that Q3MacintoshStorage_New expects a file reference  
> number, as created for example by FSpOpenDF, not a fork reference  
> number.  I'm surprised it worked at all, because I don't think the  
> two kind of reference numbers are compatible.

Oh.  For some reason, I had assumed FSOpenFork was just the FSRef  
equivalent of FSpOpenDF/FSpOpenRF.  Thanks for setting me straight.

That sort of makes it difficult to open a file without calling on  
deprecated APIs, doesn't it?  I guess you can turn an FSRef into a  
path and go that route, but paths aren't without problems either,  
from what I've heard.  I think I'll go back to using FSSpecs for now...

-Ted

Re: 3DMF export

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

On Dec 27, 2005, at 11:02 PM, Edward K.Chew wrote:

> Sorry to keep harping on about this 3DMF export business, but I  
> seem to have run into another problem with files that end  
> prematurely.  They always seem to come out an exact kilobyte  
> multiple in size, which suggests some kind of cache-flushing issue.
> As it stands, my write function makes these calls:
>
> FSOpenFork (data fork with fsWrPerm)
> Q3MacintoshStorage_New
...

I believe that Q3MacintoshStorage_New expects a file reference  
number, as created for example by FSpOpenDF, not a fork reference  
number.  I'm surprised it worked at all, because I don't think the  
two kind of reference numbers are compatible.

Re: 3DMF export

[Edward K.C. <ek...@lg...>]

Sorry to keep harping on about this 3DMF export business, but I seem  
to have run into another problem with files that end prematurely.   
They always seem to come out an exact kilobyte multiple in size,  
which suggests some kind of cache-flushing issue.
As it stands, my write function makes these calls:

FSOpenFork (data fork with fsWrPerm)
Q3MacintoshStorage_New
Q3File_New
Q3File_SetStorage
Q3File_OpenWrite
Q3View_StartWriting
do yadayada_Submit
while(Q3View_EndWriting(fileObj) == kQ3ViewStatusRetraverse)
Q3File_Close
Q3Object_Dispose(fileObj)
Q3Object_Dispose(storageObj)
FSCloseFork

Is there something wrong or missing from this sequence?

-Ted

Re: Poser 3DMFs and Quesa-RealBasic

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

On Dec 26, 2005, at 12:46 PM, Don Bice wrote:

> When I export a 3dmf from poser 6, rb crashes when trying to open  
> it. I
> have the latest update for poser.
>
> Anyone know what the deal is with poser 3dmfs?
>
> If I export a .lwo 3d object from Poser, my other 3d program Cararra
> can open it and then save it as a 3dmf. These 3dmfs from Cararra work
> fine in rb. The bad news is that in the process, a 100k 3dmf (when
> poser exports it) turns into a 1mb 3dmf when Cararra exports it. So,
> this becomes an issue when having a lot of objects/shapes in rb3d
> spaces.

If you could post an example of such a .3dmf file somewhere, I could  
try to figure out what's wrong with it.  One possibility would be to  
create a bug report at <http://sourceforge.net/tracker/? 
group_id=45158&atid=442052> and attach a sample file.

Poser 3DMFs and Quesa-RealBasic

[Don B. <bic...@ho...>]

Hello,

When I export a 3dmf from poser 6, rb crashes when trying to open it. I
have the latest update for poser.

Anyone know what the deal is with poser 3dmfs?

If I export a .lwo 3d object from Poser, my other 3d program Cararra
can open it and then save it as a 3dmf. These 3dmfs from Cararra work
fine in rb. The bad news is that in the process, a 100k 3dmf (when
poser exports it) turns into a 1mb 3dmf when Cararra exports it. So,
this becomes an issue when having a lot of objects/shapes in rb3d
spaces.

Another issue with poser is that if an object has a texture, (like
pants or a custom face) the texture gets lost when opening it in
Cararra (ive tried every 3d format).


I think all these issues would go away if Poser 3dmfs didnt make rb
crash. But, I realize this is probably Poser's fault and not quesa's
fault, but this is a serious bummer. Does anyone have any insight in
this?

Thanks.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: 3DMF export

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

Applications which read 3DMF should accept files with extensions
.3DMF , .3dmf or .3dm or any HFS file with file type '3DMF' even if
they have no extension. Microspot applications currently still
produce files with creator type '3DMF' with no extension unless
manually added by the user.

On 22 Dec, 2005, at 20:46, Edward K. Chew wrote:

> On Dec 22, 2005, at 14:29, Roger Holmes wrote:
>
>> The export of Text 3DMF has not been implemented in Quesa yet.
>> We can read text 3DMF, so any old text files you may have are safe.
>
> Okay, thanks.
>
> By the way, is the accepted file name extension for a 3DMF file  
> simply ".3dmf"?  I ask, because I have seen a number of variations  
> depending on where I look.
>
> --Ted
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: 3DMF export

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

On Dec 22, 2005, at 3:46 PM, Edward K. Chew wrote:

> By the way, is the accepted file name extension for a 3DMF file  
> simply ".3dmf"?  I ask, because I have seen a number of variations  
> depending on where I look.

Yes, .3dmf is the standard extension for either text or binary.

Re: 3DMF export

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

On Dec 22, 2005, at 3:46 PM, Edward K. Chew wrote:

> By the way, is the accepted file name extension for a 3DMF file  
> simply ".3dmf"?  I ask, because I have seen a number of variations  
> depending on where I look.

Yes, .3dmf is the standard extension for either text or binary.

Re: 3DMF export

[Edward K. C. <ek...@lg...>]

On Dec 22, 2005, at 14:29, Roger Holmes wrote:

> The export of Text 3DMF has not been implemented in Quesa yet.
> We can read text 3DMF, so any old text files you may have are safe.

Okay, thanks.

By the way, is the accepted file name extension for a 3DMF file  
simply ".3dmf"?  I ask, because I have seen a number of variations  
depending on where I look.

--Ted

Re: 3DMF export

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

The export of Text 3DMF has not been implemented in Quesa yet.
We can read text 3DMF, so any old text files you may have are safe.

Roger Holmes.

On 22 Dec, 2005, at 17:08, Edward K. Chew wrote:

> I was getting a -28292 (kQ3WarningTypeHasNotBeenRegistered) warning  
> on trying to export a 3DMF file, and the resultant file contained  
> zero bytes.  Eventually, I tried switching from kQ3FileModeText to  
> kQ3FileModeNormal and it seems happy once more.  Are ASCII 3DMFs no  
> longer supported?
>
> --Ted
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

3DMF export

[Edward K. C. <ek...@lg...>]

I was getting a -28292 (kQ3WarningTypeHasNotBeenRegistered) warning  
on trying to export a 3DMF file, and the resultant file contained  
zero bytes.  Eventually, I tried switching from kQ3FileModeText to  
kQ3FileModeNormal and it seems happy once more.  Are ASCII 3DMFs no  
longer supported?

--Ted

Re: Memory Leak with UVs set too large numbers

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

> There seems to be a memory leaks when assigning textures to shapes
> (general polygon in my example) which have been assigned UV
> coordinates with large values (a range from -500 to 500 in my example).
> When seting the UVs to a range of 0..1, the memory leaks goes away.
> Should the UV always be in range 0..1
>

No, I use numbers 0 to around 20 frequently. Maybe it is the negative
numbers which are causing the problem. Could you try adding 500 to
all your UV values so they go from 0 to 1000 instead?

Roger Holmes.

[ quesa-Bugs-1370363 ] Memory Leak with UVs set too large numbers

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

Bugs item #1370363, was opened at 2005-11-30 14:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1370363&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: nstensland (nstensland)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Leak with UVs set too large numbers

Initial Comment:
There seems to be a memory leaks when assigning textures to shapes 
(general polygon in my example) which have been assigned UV 
coordinates with large values (a range from -500 to 500 in my example). 
When seting the UVs to a range of 0..1, the memory leaks goes away. 
Should the UV always be in range 0..1
?



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

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

Re: Cocoa?

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

Hi,

Yes we are using it. We went to the universal binary kitchen in London
and came back with a simple Cocoa universal binary application which
uses Quesa Cocoa. We reported at least half a dozen bugs whilst we
were there. We are doing the development on Apple's Intel machine
using the very latest X-Code and Tiger. One of the problems is that
compiler optimisation above level two caused our App to crash.
There were issues with not stripping the code so that RTTI was
available to the program when it needed to throw out of a framework
into the application, but I think that was more to do with our
Quesa C++ wrapping Framework than with Quesa Cocoa itself, but
something to be aware of.

Roger.




On 23 Nov, 2005, at 08:21, Jose' Cruanyes wrote:

> Hi
>
> I've not get any feedback about the Cocoa version of Quesa
>
> Is there anyone using it?
>
>
> Pax et Bonum
>
> # dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,33603122                0372,460602
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>