quesa-develop — Mailing list for Quesa development

move to git, and maybe Github?

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

In view of Xcode 10 dropping support for svn, I think it would be reasonable to switch to git.  I could do that at SourceForge, but SourceForge doesn’t have such a great reputation any more, and I’m thinking it might make sense to migrate to Github (or Bitbucket) at the same time.  Opinions?

specular mapping is here

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

I just committed changes to add specular mapping to per-pixel rendering. 
  Using a custom element (CESpecularMapElement_Set) you supply a second 
texture to a surface shader.  The RGB part is the specular color and the 
alpha handles specular control.  See comments on 
CESpecularMapElement_Set in QuesaCustomElements.h for details.

Here's an example of a use for this feature: 
<http://www.jwwalker.com/quesa/shiny-ocean.mov>
This is a world globe in which the ocean is shiny and the land is not, 
implemented as a single TriMesh.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Crashing

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

Is anyone else getting crashes inside glClear? My old version of Quesa is calling it with the value 0x4100. The call chains is Q3View_StartRendering  which calls E3View_StartRendering which calls E3Renderer_Method_StartFrame which calls IRReenderer_StartFrame.

It is when Cocoa's drawRect: is imaging a picture deep inside Cocoa which was being called by GraphicsImportDoExportImageFileToDataRefDialog (Part of Quicktime image compression) so maybe doing a preview of the image. 

Roger.

Re: Optimisation.

[Don A. <da...@do...>]

On 2012-06-18, at 9:12 PM, James Walker wrote:

> I just committed a fix (svn r. 3240) that should fix your texture bug.
> 
> In case anyone is curious what the problem was: 
> E3ClassTree::RegisterClass is passed instanceSize (the total size of an 
> instance of the class) and deltaInstanceSize (the size of leaf instance 
> data, the data beyond the superclass).  Quesa was assuming that it could 
> locate the leaf instance data by going to the end of the instance and 
> backing up by deltaInstanceSize.  However, this is not correct if 
> padding gets added to the end of the leaf instance data.  The base 
> class, OpaqueTQ3Object, contains pointers, so every instance of every 
> subclass is padded to a multiple of the size of a pointer.


Thanks James, that did it. Very much appreciated.

Best Regards,
Don Agro

Re: Optimisation.

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

On 6/17/2012 7:50 PM, Don Agro wrote:
> Hi,
>
> On 2012-05-29, at 11:04 AM, Roger Holmes wrote:
>
>> I hope my recent changes work for everyone still using Quesa, I have
>> no idea how many that is now.
>
> We are still using it - works great!
>
> I have run into a problem with 64 bit though - creating a texture from a
> file (latest GNU tarball http://quesa.svn.sourceforge.net/viewvc/quesa/)
> - works fine in 32 bit mode but the texture is deformed in 64 bit -
> anyone else ?
>
> Any comments appreciated.

I just committed a fix (svn r. 3240) that should fix your texture bug.

In case anyone is curious what the problem was: 
E3ClassTree::RegisterClass is passed instanceSize (the total size of an 
instance of the class) and deltaInstanceSize (the size of leaf instance 
data, the data beyond the superclass).  Quesa was assuming that it could 
locate the leaf instance data by going to the end of the instance and 
backing up by deltaInstanceSize.  However, this is not correct if 
padding gets added to the end of the leaf instance data.  The base 
class, OpaqueTQ3Object, contains pointers, so every instance of every 
subclass is padded to a multiple of the size of a pointer.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Optimisation.

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

I am using quesa and it work nicely for me.

Il 29/05/2012 17.04, Roger Holmes ha scritto:
> I have found that when displaying one of my documents using the interactive renderer, the main CPU spends a lot of time in IRRenderer_Update_Matrix_LocalToCamera, mainly inverting a matrix.
>
> The matrix only gets used to transform the origin and a unit vector along the minus Z axis so most of its elements do not get used. Could this be optimised fairly easily? In fact most calls to this are when popping the view stack and so if we were to hold the local camera position and the view vector on the view stack, all this would be unnecessary but maybe that is too big a structural change. If so, could a a cut down version of Q3Matrix4x4_Invert be used?
>
> I hope my recent changes work for everyone still using Quesa, I have no idea how many that is now.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

-- 
Daniele Cavallini
Interstudio s.r.l.
Piazza Monteoliveto 6/A 51100 Pistoia - Italy
Tel. +39 0573 99291 - Fax +39 0573 992930
www.interstudio.net dca...@in...

Re: Optimisation.

[Don A. <da...@do...>]

Hi,

On 2012-05-29, at 11:04 AM, Roger Holmes wrote:

> I hope my recent changes work for everyone still using Quesa, I have no idea how many that is now.

We are still using it - works great!

I have run into a problem with 64 bit though - creating a texture from a file (latest GNU tarball http://quesa.svn.sourceforge.net/viewvc/quesa/) - works fine in 32 bit mode but the texture is deformed in 64 bit - anyone else ?

Any comments appreciated.

Thanks,

TQ3ShaderObject createTextureFromFile(NSString * fileName) {    // doesn't work in 64 bit
	
	// create the texture return shader object or null if error

	TQ3ShaderObject		shader = NULL;
	NSBitmapImageRep	*theImage;	
    
    NSLog(@"createTextureFromFile:fileName:[%@]", fileName);
    
	NSString *resourcePath = [[NSBundle mainBundle] resourcePath];
    theImage = [NSBitmapImageRep imageRepWithContentsOfFile: [resourcePath stringByAppendingString:fileName]];

	if (theImage) {
		int		bitsPPixel, theWidth, theHeight, rowBytes;
		bitsPPixel	= [theImage bitsPerPixel];
		rowBytes	= [theImage bytesPerRow];
		theWidth	= [theImage pixelsWide];
		theHeight	= [theImage pixelsHigh];


		NSLog(@"createTextureFromFile: imageRepWithContentsOfFile OK: width = %d, height = %d,  %d bpp, %d rowBytes\n",
					theWidth, theHeight, bitsPPixel, rowBytes);
		
		TQ3TextureObject		qd3dTextureObject;						
		TQ3StoragePixmap		qd3dPixMap;
		TQ3StorageObject		qd3dMemoryStorage;
		TQ3PixelType			pixelType = kQ3PixelTypeRGB24;
		
		switch (bitsPPixel) {
			case 16: pixelType = kQ3PixelTypeRGB16; break;
			case 24: pixelType = kQ3PixelTypeRGB24; break;
			case 32: pixelType = kQ3PixelTypeARGB32; break;
		}
		
		qd3dMemoryStorage		= Q3MemoryStorage_New([theImage bitmapData], theHeight * rowBytes);
		if (qd3dMemoryStorage) {
			qd3dPixMap.image        = qd3dMemoryStorage;
			qd3dPixMap.width	= theWidth;
			qd3dPixMap.height	= theHeight;
			qd3dPixMap.rowBytes	= rowBytes;
			qd3dPixMap.pixelSize	= bitsPPixel;
			qd3dPixMap.pixelType	= pixelType;
			qd3dPixMap.bitOrder	= kQ3EndianBig;
			qd3dPixMap.byteOrder	= kQ3EndianBig;
			qd3dTextureObject	= Q3PixmapTexture_New(&qd3dPixMap);
			if (qd3dTextureObject) {	// create shader from textured object
				shader = Q3TextureShader_New(qd3dTextureObject);
				Q3Object_Dispose(qd3dTextureObject);
			}
			Q3Object_Dispose(qd3dMemoryStorage);
		}

	}
	return shader;
}

d agro
www: http://www.dogparksoftware.com

Re: Optimisation.

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

On May 29, 2012, at 12:57 PM, James Walker wrote:

>> I hope my recent changes work for everyone still using Quesa, I have no idea how many that is now.
> 
> 
> Yes, I'm curious whether anyone else is still here!

Still here, have a couple older Windows applications that use Quesa which are still being sold.

-lane

Re: Optimisation.

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

On Tue, 29 May 2012 10:57:23 -0700, James Walker said:

>> I hope my recent changes work for everyone still using Quesa, I have
>no idea how many that is now.
>
>Yes, I'm curious whether anyone else is still here!

We still use Quesa, but only to open 3dmf files that were persisted in our older file format.  We don't do any rendering with Quesa.

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Optimisation.

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

On 5/29/2012 8:04 AM, Roger Holmes wrote:
> I have found that when displaying one of my documents using the
> interactive renderer, the main CPU spends a lot of time in
> IRRenderer_Update_Matrix_LocalToCamera, mainly inverting a matrix.


I only use the OpenGL renderer.  Remind me why you still use the IR?


> The matrix only gets used to transform the origin and a unit vector
> along the minus Z axis so most of its elements do not get used.


More precisely, exactly half of its elements get used, row 3 and row 4. 
  Though, depending on whether the camera is orthographic, just one of 
these is used, not both.


> Could this be optimised fairly easily? In fact most calls to this are when
> popping the view stack and so if we were to hold the local camera
> position and the view vector on the view stack, all this would be
> unnecessary but maybe that is too big a structural change. If so, could
> a cut down version of Q3Matrix4x4_Invert be used?


Another possibility might be to do the inversion and transformations 
lazily, similar to the way the IR already handles 
stateMatrixLocalToCameraInvTr and stateMatrixLocalToCameraInvTrValid. 
IRRenderer_Update_Matrix_LocalToCamera and ir_state_reset would just set 
an "invalid" flag, and the real work would be done in 
IRGeometry_Generate_Triangle_Flags.


> I hope my recent changes work for everyone still using Quesa, I have no idea how many that is now.


Yes, I'm curious whether anyone else is still here!
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Optimisation.

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

I have found that when displaying one of my documents using the interactive renderer, the main CPU spends a lot of time in IRRenderer_Update_Matrix_LocalToCamera, mainly inverting a matrix. 

The matrix only gets used to transform the origin and a unit vector along the minus Z axis so most of its elements do not get used. Could this be optimised fairly easily? In fact most calls to this are when popping the view stack and so if we were to hold the local camera position and the view vector on the view stack, all this would be unnecessary but maybe that is too big a structural change. If so, could a a cut down version of Q3Matrix4x4_Invert be used?

I hope my recent changes work for everyone still using Quesa, I have no idea how many that is now.

Re: Speeding up file saving.

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

On 5/21/2012 6:38 AM, Roger Holmes wrote:
> Hi all,
>
> In my copy of Quesa I have speeded up file saving. For a file with
> 8000 cubes, each made up of six general polygons, each made of two
> triangles, the save time came down from 5.5 MINUTES to 5 SECONDS. If
> anyone else actually does saving then the change is quite small though
> it does use up 4 bytes in every single Quesa object so maybe you would
> not like that. I can't remember how to check in to Quesa any more but
> the change is very small so I can provide all the minute detail if you
> would like the details.

I do occasionally save files, but I haven't noticed that much of a 
problem with the speed.  Please send me both the details of the change 
and your test case (either C/C++ code to generate it, or the binary 3DMF 
file).

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

Speeding up file saving.

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

Hi all,

In my copy of Quesa I have speeded up file saving. For a file with 8000 cubes, each made up of six general polygons, each made of two triangles, the save time came down from 5.5 MINUTES to 5 SECONDS. If anyone else actually does saving then the change is quite small though it does use up 4 bytes in every single Quesa object so maybe you would not like that. I can't remember how to check in to Quesa any more but the change is very small so I can provide all the minute detail if you would like the details.

Roger Holmes,
Technical Director,
Microspot Ltd.

[ quesa-Bugs-902976 ] Custom elements not read from 3DMF files

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

Bugs item #902976, was opened at 2004-02-23 13:02
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902976&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
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom elements not read from 3DMF files

Initial Comment:
Custom elements (such as names assigned with 
CENameElement_SetData) are not read from 3DMF files.

------- Additional Comments From James W. Walker 2002-05
-17 13:32 -------

Custom elemenst on display groups, trimeshes, and ellipsoids are 
now read.

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

>Comment By: James W. Walker (jwwalker)
Date: 2012-03-24 16:54

Message:
Name elements now work in text-form 3DMF, in the cases where they already
worked in binary 3DMF.

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

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

Re: Android version of Quesa?

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

On Mar 14, 2012, at 8:09 AM, Jim Witte wrote:

> Is there an Android version of the Quesa rendering layer?

No.  It's my understanding that Android uses OpenGL ES, rather than the older flavor of OpenGL used by Quesa, so it would probably be a fair amount of work to adapt Quesa to Android.

Android version of Quesa?

[Jim W. <jim...@gm...>]

Is there an Android version of the Quesa rendering layer?

Re: Custom attribute for refractive index

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

On 2/6/2012 8:41 AM, Roger Holmes wrote:

> I see that emissive colour has been added to the built in attributes.
> Is this because it could not be made to work as a custom attribute?

Since emissive color is built in to the fixed functionality of OpenGL, I 
just thought it was natural to make it a built in attribute.  I don't 
think I ever tried to make a custom attribute.

> I am having problems getting it to work that way, could I add
> refractive index to the built in attributes too? It would save some
> processing time for items which do not have a refractive index. I think
> over half the bits in the mask are free at the moment.

I suppose that would be all right.  The view stack state bits are 
tighter, with 29 out of 32 being used, but I guess we could use a 64-bit 
integer for that if the need arises.

>
>
> On 4 Feb 2012, at 23:54, James W. Walker wrote:
>
>>
>> On Feb 2, 2012, at 5:34 AM, Roger Holmes wrote:
>>
>>> I intend to do a custom attribute for refractive index which be picked up by the RayShade Renderer. Am I re-inventing the wheel? If so would it make sense to use the same attribute ID?
>>
>> Doesn't ring any bells for me.


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

Re: Custom attribute for refractive index

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

Thanks.
\
On 6 Feb 2012, at 18:48, James Walker wrote:

> On 2/6/2012 8:41 AM, Roger Holmes wrote:
> 
>> I see that emissive colour has been added to the built in attributes.
>> Is this because it could not be made to work as a custom attribute?
> 
> Since emissive color is built in to the fixed functionality of OpenGL, I just thought it was natural to make it a built in attribute.  I don't think I ever tried to make a custom attribute.
> 
>> I am having problems getting it to work that way, could I add
>> refractive index to the built in attributes too? It would save some
>> processing time for items which do not have a refractive index. I think
>> over half the bits in the mask are free at the moment.
> 
> I suppose that would be all right.  The view stack state bits are tighter, with 29 out of 32 being used, but I guess we could use a 64-bit integer for that if the need arises.
> 
>> 
>> 
>> On 4 Feb 2012, at 23:54, James W. Walker wrote:
>> 
>>> 
>>> On Feb 2, 2012, at 5:34 AM, Roger Holmes wrote:
>>> 
>>>> I intend to do a custom attribute for refractive index which be picked up by the RayShade Renderer. Am I re-inventing the wheel? If so would it make sense to use the same attribute ID?
>>> 
>>> Doesn't ring any bells for me.
> 
> 
> -- 
>  James W. Walker, Innoventive Software LLC
>  <http://www.frameforge3d.com/>

Re: Custom attribute for refractive index

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

I see that emissive colour has been added to the built in attributes. Is this because it could not be made to work as a custom attribute? I am having problems getting it to work that way, could I add refractive index to the built in attributes too? It would save some processing time for items which do not have a refractive index. I think over half the bits in the mask are free at the moment.


On 4 Feb 2012, at 23:54, James W. Walker wrote:

> 
> On Feb 2, 2012, at 5:34 AM, Roger Holmes wrote:
> 
>> I intend to do a custom attribute for refractive index which be picked up by the RayShade Renderer. Am I re-inventing the wheel? If so would it make sense to use the same attribute ID?
> 
> Doesn't ring any bells for me.
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Custom attribute for refractive index

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

On Feb 2, 2012, at 5:34 AM, Roger Holmes wrote:

> I intend to do a custom attribute for refractive index which be picked up by the RayShade Renderer. Am I re-inventing the wheel? If so would it make sense to use the same attribute ID?

Doesn't ring any bells for me.

Custom attribute for refractive index

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

Hi All,

I intend to do a custom attribute for refractive index which be picked up by the RayShade Renderer. Am I re-inventing the wheel? If so would it make sense to use the same attribute ID?

Roger.

Custom attribute for refractive index

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

Hi All,

I intend to do a custom attribute for refractive index which be picked up by the RayShade Renderer. Am I re-inventing the wheel? If so would it make sense to use the same attribute ID?

Roger.

Re: Custom geometries

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

I have finally got this to work. If anyone want to do something similar some time I can help.

When I catch up to using the latest version of Quesa I might want to make some changes to make it easier. In particular the way you have to predict in advance the size of the objects you are going to write is rather silly considering Quesa does not actually write them until later and also modifies the size you have specified. It should just take the file position before and after writing and deduct one from the other to get the size. A C++ stack based constructor (which remembers the file position) and destructor (which does the subtraction and writes the result to the stream) would probably be ideal.

I also hate the reader having a method of the same type as its object type ID, this would be much better as an ordinary fixed methods in the class' meta handler, where needed one for each format though does not seem to be much used for anything but basic types (endian correction and text format etc).

Anyway, for now it works though it is rather cobbled together and has to use a few of Quesa's private header files which I dislike having to do.

Thanks for your help.






On 23 Nov 2011, at 19:48, James Walker wrote:

> On 11/23/2011 8:45 AM, Roger Holmes wrote:
>> I've been stepping through Quesa trying to find out how to do this.
>> As  best I can tell I need to add a method to the file format class with the
>> TYPE of my custom class as the method identifier. What I can't see is
>> how I get hold of the file format class when I register my class just
>> after initialising Quesa. The file format class object does not seem to
>> exist yet.
> 
> I don't see why that would be.  The file format, file format reader, and 
> file format writer classes are registered by E3FileFormat_RegisterClass, 
> which is called by E3File_RegisterClass, which is called by E3Initialize.
> 
> 
>> If I try to leave it until later then I do not get called at
>> all so cannot register the method. Surely my custom class's meta handler
>> should get called somewhere along the line when Quesa cannot find a
>> suitable method rather than giving up and decomposing the geometry?
> 
> 
> I think it's quite possible that when Quesa was written, nobody 
> anticipated a need for custom geometry I/O.  You may need to figure out 
> what Quesa *ought* to do, and write the code to do it.
> 
>> 
>> 
>> 
>> 
>> On 9 Nov 2011, at 17:05, James W. Walker wrote:
>> 
>>> 
>>> On Nov 9, 2011, at 7:43 AM, Roger Holmes wrote:
>>> 
>>>> Can someone please help me with a problem I am having.
>>>> 
>>>> I have defined a custom geometry and it working well in the program but is not saving correctly. I should have added methods in the meta handler for reading and writing the data. I can see separate methods for immediate and retained writing but cannot see methods for reading at all.
>>>> 
>>>> Why are there separate methods for immediate and retained writing? Can one call the other?
>>>> 
>>>> Why is there no method for reading? How is reading of custom objects handled?
>>> 
>>> 
>>> It sounds like you're looking at kQ3XMethodTypeViewSubmitRetainedWrite and kQ3XMethodTypeViewSubmitImmediateWrite.  Those would be used for implementing a custom view object, not a custom geometry object.
>>> 
>>> I've never done a custom geometry, but I imagine that for I/O you'd use kQ3XMethodTypeObjectTraverse, kQ3XMethodTypeObjectWrite, and kQ3XMethodTypeObjectReadData, as with custom elements.
>>> 
>>> 
>>>> Is there any sample code for custom object reading and writing?
>>> 
>>> 
>>> I'm not aware of any sample code for reading and writing other than for custom elements, such as the code in E3CustomElements.c.
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> RSA(R) Conference 2012
>>> Save $700 by Nov 18
>>> Register now
>>> http://p.sf.net/sfu/rsa-sfdev2dev1
>>> _______________________________________________
>>> Quesa-develop mailing list
>>> Que...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>> 
>> 
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>> 
> 
> 
> -- 
>   James W. Walker, Innoventive Software LLC
>   <http://www.frameforge3d.com/>
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Custom geometries

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

On 11/23/2011 8:45 AM, Roger Holmes wrote:
> I've been stepping through Quesa trying to find out how to do this.
> As  best I can tell I need to add a method to the file format class with the
> TYPE of my custom class as the method identifier. What I can't see is
> how I get hold of the file format class when I register my class just
> after initialising Quesa. The file format class object does not seem to
> exist yet.

I don't see why that would be.  The file format, file format reader, and 
file format writer classes are registered by E3FileFormat_RegisterClass, 
which is called by E3File_RegisterClass, which is called by E3Initialize.


> If I try to leave it until later then I do not get called at
> all so cannot register the method. Surely my custom class's meta handler
> should get called somewhere along the line when Quesa cannot find a
> suitable method rather than giving up and decomposing the geometry?


I think it's quite possible that when Quesa was written, nobody 
anticipated a need for custom geometry I/O.  You may need to figure out 
what Quesa *ought* to do, and write the code to do it.

>
>
>
>
> On 9 Nov 2011, at 17:05, James W. Walker wrote:
>
>>
>> On Nov 9, 2011, at 7:43 AM, Roger Holmes wrote:
>>
>>> Can someone please help me with a problem I am having.
>>>
>>> I have defined a custom geometry and it working well in the program but is not saving correctly. I should have added methods in the meta handler for reading and writing the data. I can see separate methods for immediate and retained writing but cannot see methods for reading at all.
>>>
>>> Why are there separate methods for immediate and retained writing? Can one call the other?
>>>
>>> Why is there no method for reading? How is reading of custom objects handled?
>>
>>
>> It sounds like you're looking at kQ3XMethodTypeViewSubmitRetainedWrite and kQ3XMethodTypeViewSubmitImmediateWrite.  Those would be used for implementing a custom view object, not a custom geometry object.
>>
>> I've never done a custom geometry, but I imagine that for I/O you'd use kQ3XMethodTypeObjectTraverse, kQ3XMethodTypeObjectWrite, and kQ3XMethodTypeObjectReadData, as with custom elements.
>>
>>
>>> Is there any sample code for custom object reading and writing?
>>
>>
>> I'm not aware of any sample code for reading and writing other than for custom elements, such as the code in E3CustomElements.c.
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>


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

Re: Custom geometries

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

I've been stepping through Quesa trying to find out how to do this. As best I can tell I need to add a method to the file format class with the TYPE of my custom class as the method identifier. What I can't see is how I get hold of the file format class when I register my class just after initialising Quesa. The file format class object does not seem to exist yet. If I try to leave it until later then I do not get called at all so cannot register the method. Surely my custom class's meta handler should get called somewhere along the line when Quesa cannot find a suitable method rather than giving up and decomposing the geometry?




On 9 Nov 2011, at 17:05, James W. Walker wrote:

> 
> On Nov 9, 2011, at 7:43 AM, Roger Holmes wrote:
> 
>> Can someone please help me with a problem I am having.
>> 
>> I have defined a custom geometry and it working well in the program but is not saving correctly. I should have added methods in the meta handler for reading and writing the data. I can see separate methods for immediate and retained writing but cannot see methods for reading at all.
>> 
>> Why are there separate methods for immediate and retained writing? Can one call the other?
>> 
>> Why is there no method for reading? How is reading of custom objects handled?
> 
> 
> It sounds like you're looking at kQ3XMethodTypeViewSubmitRetainedWrite and kQ3XMethodTypeViewSubmitImmediateWrite.  Those would be used for implementing a custom view object, not a custom geometry object.
> 
> I've never done a custom geometry, but I imagine that for I/O you'd use kQ3XMethodTypeObjectTraverse, kQ3XMethodTypeObjectWrite, and kQ3XMethodTypeObjectReadData, as with custom elements.
> 
> 
>> Is there any sample code for custom object reading and writing?
> 
> 
> I'm not aware of any sample code for reading and writing other than for custom elements, such as the code in E3CustomElements.c.
> 
> 
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop