quesa-develop — Mailing list for Quesa development

[ quesa-Bugs-922742 ] Alpha textures do not work properly with fog or specularity

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Alpha textures do not work properly with fog or specularity

Initial Comment:
In order to mimic QD3D's pre-multiplied alpha behaviour, Quesa 
resorts to using an additive blend mode for textures with alpha bits 
(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). This works for the most 
part, but results in vertex effects like fog and specular highlights 
being blended additively over entire polygons rather than clipping 
to the alpha channel, as they would when using a blend mode like 
(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). QD3D does not 
display these artifacts, so binary compatibility is compromised in 
these cases.

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 22:45

Message:
Logged In: YES 
user_id=439944

Can you attach a model demonstrating the problem?

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

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

[ quesa-Bugs-922421 ] Severe Memory Leak caused by Resizing View (x86 only)

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Tom Sanham (tomsanham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Severe Memory Leak caused by Resizing View (x86 only)

Initial Comment:
Platform: 
Windows XP
Quesa 1.6d18

To reproduce:

- Load GeomTest.exe
- Open 'Windows Task Manager'
- Resize the GeomTest window repeatedly
- 'Commit Charge' value in the Windows Task Manager 
window increases by a few MB with each resize. This 
lost memory is only reclaimed on quitting GeomTest

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

>Comment By: Dair Grant (grantd)
Date: 2004-06-15 22:44

Message:
Logged In: YES 
user_id=439944

Closing this as won't fix - this is almost certainly a bug they've 
introduced in their drivers, and as such not something we can do 
anything about.

The fact that the other x86 machines all run without the memory leak 
would imply we're not doing anything untoward on that platform, and so 
the best chance for a resolution would be to send a copy of Geom Test to 
SiS and ask them to fix the leak.

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

Comment By: Tom Sanham (tomsanham)
Date: 2004-03-31 15:40

Message:
Logged In: YES 
user_id=982065

More testing has indicated that the problem is related to 
video driver / card. Details are below.

The original machine setup giving the problem described is:

(1) Windows XP Home Ver 2002 SP 1, SiS 650 Rev 00

A second machine with nearly the same setup as the first did 
_not_ give the problem.

(2) Windows XP Home Ver 2002 SP 1, SiS 650 Rev 00

The only significant difference in setup was that machine (1) 
had the latest video drivers installed (SiS650 version 2.22 XP 
drivers) , and machine (2) had the factory video drivers 
installed.

To prove that the new video drivers were the culprit, we 
installed the latest video drivers onto machine (2), and since 
then, this machine gives the problem as well.

Other machines we tested, none of which gave the problem 
are:
(3) Windows XP Home Ver 2002, SP 1,  Graphics: Intel 82845G
(4) Windows XP Home Ver 2002, SP 1,  Graphics: Intel 82845G
(5) Windows XP Pro Ver 2002 SP 1, Graphics: NVIDIA GeForce 
FX5200
(6) Windows 98 SE 4.10.2222A, Graphics: SiS 530 Rev A2


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

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

Re: Partial "objecting" success

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

On Tue, 15 Jun 2004, Keith Wiley wrote:

> On Tue, 15 Jun 2004, Frank C wrote:
>
> > You'll have to dig through the trimesh's vertexAttributeTypes until you
> > find an array of the type kQ3AttributeTypeShadingUV, then duplicate
> > that information and append that array to match the extra vertices.
>
> I see that the trimesh has at attribute with that type, which contains an
> array...but how do I know how long the array is?  And where can I find a
> description of the contents of this array?  Is it a list of UV coordinates
> for the vertices?  If so, I would guess that the array is twice as long as
> the number of vertices in the object, one U and one V coordinate per
> vertex.  Is that right?

Actually, I'm studying the online PDF "Making Cool QuickDraw 3D
Applications" and it looks like the attributes array is the same length as
the number of vertices, which each element being a 2D UV coord.

I'll have to work on this some, it seems pretty clear now though.

Thanks for the tips.

________________________________________________________________________
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: Partial "objecting" success

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

On 15-Jun-04, at 1:05 PM, Keith Wiley wrote:

> On Tue, 15 Jun 2004, Frank C wrote:
>
>> You'll have to dig through the trimesh's vertexAttributeTypes until 
>> you
>> find an array of the type kQ3AttributeTypeShadingUV, then duplicate
>> that information and append that array to match the extra vertices.
>
> I see that the trimesh has at attribute with that type, which contains 
> an
> array...but how do I know how long the array is?  And where can I find 
> a
> description of the contents of this array?  Is it a list of UV 
> coordinates
> for the vertices?  If so, I would guess that the array is twice as 
> long as
> the number of vertices in the object, one U and one V coordinate per
> vertex.  Is that right?

Yup - all built-in vertexAttributeTypes must contain an entry for each 
vertex, and the size of each depends on the type; 2 floats for UVs, 3 
floats for colours/normals etc., so the array is always 
typesize*numPoints.

Frank.

Re: Memory storage growth

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

Sounds good to me.


On Friday, June 11, 2004, at 07:13  pm, James W. Walker wrote:

> While trying to write a large object to a memory storage object, I 
> noticed that more than half the time was spent in 
> e3storage_memory_grow.  Memory storage objects grow linearly, but it 
> is well known that you get better performance if you grow buffers 
> exponentially (e.g., double the size each time you need to grow.) 
> Shall I make exponential growth an option, or just change the standard 
> behavior?  I can't think of any reason that existing software would be 
> hurt by the change.

Re: Does the number of objects matter?

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

Actually the vertex array is transformed when rendered, but every 
vertex gets
the same transformation applied to it to give world coordinates.

The TriMesh has many arrays, one for vertices, one for edges, one for 
triangles
and also ones for attributes which can be attached to any of those.

To combine two trees you need to double up the sizes of each of these 
arrays
and fill out all the values. For the vertices you will need to apply a 
translation
only, unless you need to scale as well for large trees and small trees. 
Of course
you also might like to rotate them about the vertical axis or even lean 
them over
a bit at the same time. For the triangles, they hold the indices of the 
vertices, so
the second tree would need to add the original count of the number of 
vertices
so that it picks up the second set instead of the first set. Similarly 
for the edges.

The attribute arrays just need replicating as I presume any colours etc 
would
remain the same.

Roger.


On Tuesday, June 15, 2004, at 03:27  pm, Keith Wiley wrote:

> I don't see how I can do this with one TriMesh for the following 
> reason.  In the debugger I have observed that the TriMesh has an array 
> of 3D points, clearly the vertices.  However, these points are not a 
> global definition which is then translated, rotated, and scaled at the 
> time of rendering.  The points store such changes, so there doesn't 
> seem to be anyway for one TriMesh to refer to two trees that are next 
> to each other since the points need to be in different locations.
>
> What's going on here?  How do I combine them in that way?
>
> Roger Holmes wrote:
>
>> You would probably want something more along the lines of one TriMesh 
>> for all the
>> brown tree trunks/branches and another for all the green foliage.
>>
>>
>> On Tuesday, June 15, 2004, at 06:35  am, Keith Wiley wrote:
>>
>>>
>>> Okay, I see.  So, if in Meshwork I create a tree, then copy and 
>>> paste it next to the original tree so I have two separate trees, 
>>> with totally unconnected vertices, I can save the entire thing not 
>>> only as a group (which doesn't do much) but as a single "object" 
>>> even though it is clearly physically two separate objects.
>>>
>>> And likewise, I could take individual trees after opening them into 
>>> the program and combine them into a single object.  Right?  I'll 
>>> study the trimesh code.  I guess what would be nice is to only have 
>>> the trimesh stored once and then specify that it is simply placed in 
>>> the world multiple times.  Is that on the right track?
>>

Re: Partial "objecting" success

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

On Tue, 15 Jun 2004, Frank C wrote:

> You'll have to dig through the trimesh's vertexAttributeTypes until you
> find an array of the type kQ3AttributeTypeShadingUV, then duplicate
> that information and append that array to match the extra vertices.

I see that the trimesh has at attribute with that type, which contains an
array...but how do I know how long the array is?  And where can I find a
description of the contents of this array?  Is it a list of UV coordinates
for the vertices?  If so, I would guess that the array is twice as long as
the number of vertices in the object, one U and one V coordinate per
vertex.  Is that 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: Partial "objecting" success

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

On 15-Jun-04, at 11:40 AM, Keith Wiley wrote:

> However, it can't handle textures.  If the objects have no texturing, 
> just colored faces, everything works great, but if the objects had a 
> texture mapped to the faces, it draws the new "merged" object such 
> that the original object (the one in the first half of the arrays) 
> displays correctly, but the second one that I added to it is a 
> complete mess.
> ...
>
> I guess the solution is to use pinned mapping and make sure the two 
> objects retain their UV pin assignments (for now the separate objects 
> are identical anyway, so the vertex assignment (the shape), and the 
> texture, and the UV pinning are identical, except for a vertex 
> translation.

The coordinates will be converted to UV when exported to 3DMF 
regardless of the projection you're using in Meshwork, so this isn't 
necessary AFAIK...

> So with that said, I am unsure where to find the UV pin assignments 
> for a pinned texture.  How do I get access to that data for a 
> particular TriMesh?  I hope the question even makes sense.

You'll have to dig through the trimesh's vertexAttributeTypes until you 
find an array of the type kQ3AttributeTypeShadingUV, then duplicate 
that information and append that array to match the extra vertices.

You may need to do something similar for the vertex normals as well, 
although they'll also need to be transformed to match the transformed 
vertices.

Frank.

Partial "objecting" success

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

Success first, problems and questions at the bottom:

I successfully opened two seperate 3DMF files and combined them into a 
single object with a single trimesh of two distinct sets of disconnected 
vertices.  I did this simply be appending the points array and triangles 
array of one trimesh to the other and incrementing the triangle/point 
assignments of the second object by the length of the first object's 
point array.  It worked and rendered perfrectly.

However, it can't handle textures.  If the objects have no texturing, 
just colored faces, everything works great, but if the objects had a 
texture mapped to the faces, it draws the new "merged" object such that 
the original object (the one in the first half of the arrays) displays 
correctly, but the second one that I added to it is a complete mess.

Ideally of course, it would be nice if the planar texture assignment, 
(I'm just using Planar mapping in Meshwork) translated to the second 
object...but now that I think about this, I guess this won't work since 
the texture must be planar mapped to the entire object.  The only reason 
the first object even displays correctly is that I didn't actually 
reassign the plane of the object to encompass both objects.  If I had, 
then both objects would display wrong.

I guess the solution is to use pinned mapping and make sure the two 
objects retain their UV pin assignments (for now the separate objects 
are identical anyway, so the vertex assignment (the shape), and the 
texture, and the UV pinning are identical, except for a vertex translation.

So with that said, I am unsure where to find the UV pin assignments for 
a pinned texture.  How do I get access to that data for a particular 
TriMesh?  I hope the question even makes sense.


________________________________________________________________________
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: Does the number of objects matter?

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

I don't see how I can do this with one TriMesh for the following 
reason.  In the debugger I have observed that the TriMesh has an array 
of 3D points, clearly the vertices.  However, these points are not a 
global definition which is then translated, rotated, and scaled at the 
time of rendering.  The points store such changes, so there doesn't seem 
to be anyway for one TriMesh to refer to two trees that are next to each 
other since the points need to be in different locations.

What's going on here?  How do I combine them in that way?

Roger Holmes wrote:

> You would probably want something more along the lines of one TriMesh 
> for all the
> brown tree trunks/branches and another for all the green foliage.
>
>
> On Tuesday, June 15, 2004, at 06:35  am, Keith Wiley wrote:
>
>>
>> Okay, I see.  So, if in Meshwork I create a tree, then copy and paste 
>> it next to the original tree so I have two separate trees, with 
>> totally unconnected vertices, I can save the entire thing not only as 
>> a group (which doesn't do much) but as a single "object" even though 
>> it is clearly physically two separate objects.
>>
>> And likewise, I could take individual trees after opening them into 
>> the program and combine them into a single object.  Right?  I'll 
>> study the trimesh code.  I guess what would be nice is to only have 
>> the trimesh stored once and then specify that it is simply placed in 
>> the world multiple times.  Is that on the right track?
>

________________________________________________________________________
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: Does the number of objects matter?

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

James W. Walker wrote:

> On Jun 14, 2004, at 10:35 PM, Keith Wiley wrote:
>
>
>> And likewise, I could take individual trees after opening them into 
>> the program and combine them into a single object.  Right?
>
>
> Yes, that's possible.
>
>>   I'll study the trimesh code.  I guess what would be nice is to only 
>> have the trimesh stored once and then specify that it is simply 
>> placed in the world multiple times.  Is that on the right track?
>
>
> That's different.  If you have multiple references to the same 
> TriMesh, with different transforms, then it will save memory, but not 
> help with speed.

Oh, okay, then I'm still not sure *how* precisely to combine objects as per the first half of the above posts.  So I open a 3DMF file of a tree into an object.  Then I clone or copy that tree and move the individual clones to different locations in the forest (or I could open the file multiple times, once per tree, I don't think it matters, Queeg has an Object cloning routine is all I'm saying).  Then I want to combine all these different trees (from the same 3DMF model) into a single "object".

How is that done exactly?

________________________________________________________________________
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: Does the number of objects matter?

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

You would probably want something more along the lines of one TriMesh 
for all the
brown tree trunks/branches and another for all the green foliage.


On Tuesday, June 15, 2004, at 06:35  am, Keith Wiley wrote:

>
> Okay, I see.  So, if in Meshwork I create a tree, then copy and paste 
> it next to the original tree so I have two separate trees, with 
> totally unconnected vertices, I can save the entire thing not only as 
> a group (which doesn't do much) but as a single "object" even though 
> it is clearly physically two separate objects.
>
> And likewise, I could take individual trees after opening them into 
> the program and combine them into a single object.  Right?  I'll study 
> the trimesh code.  I guess what would be nice is to only have the 
> trimesh stored once and then specify that it is simply placed in the 
> world multiple times.  Is that on the right track?

Fwd: Cron <grantd@sc8-pr-shell1> cd /home/users/g/gr/grantd/bin; ./co_web

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

Cron Daemon wrote:

>cvs [export aborted]: reading from server: Connection reset by peer
>mv: can't stat source /home/users/g/gr/grantd/tmp/quesa/Documentation/*

Looks like the web site update failed last night as well, so I've
replaced the script with one that moves the old site out of the way then
checks out directly to the area being served from.

So provided the checking out works, the only thing that should fail to
be deleted is the previous copy under ~grantd/tmp.


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

[ quesa-Bugs-973022 ] Specular highlights in transparent pass aren't sorted

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

Bugs item #973022, was opened at 2004-06-15 03:03
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=973022&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Specular highlights in transparent pass aren't sorted

Initial Comment:
The specular highlight pass for transparent triangles waits till all 
the transparent triangles are drawn, then blends highlights after 
the fact. The problem is, the highlights are drawn on top of 
everything in the colour buffer, so highlights on transparent 
triangles that are occluded by other transparent triangles are 
drawn full strength when they should appear to be filtered through 
the triangle in front.

A solution would be to draw each Phong shaded primitive in two 
passes when first sorted, rather than drawing the entire list of 
Phong shaded primitives as a second self-contained pass.

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

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

Patch for bug #895106

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

Here's a few modified files:  
<http://webhome.idirect.com/~frankco/895106patch.zip> that fix bug  
#895106 "Colours have no effect on textured geometry"  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=895106&group_id=45158&atid=442052>.

This patch mimics QD3D 1.6's behaviour, modulating vertex colours with  
textures for null shaded geometry, as described here:  
<http://developer.apple.com/documentation/QuickTime/QD3D/ 
QD3DDelta.htm#_Toc438524142>. It also unifies a temp fix from the  
trimesh renderer that prevents lit textured geometry from modulating  
vertex colours when going through the tribuffer path.

This patch appears to work in all my test cases, but I'd appreciate any  
criticisms or improvements!

Thanks,
Frank.

Re: Does the number of objects matter?

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

On Jun 14, 2004, at 10:35 PM, Keith Wiley wrote:

> Okay, I see.  So, if in Meshwork I create a tree, then copy and paste 
> it next to the original tree so I have two separate trees, with 
> totally unconnected vertices, I can save the entire thing not only as 
> a group (which doesn't do much) but as a single "object" even though 
> it is clearly physically two separate objects.

Sounds right (though I'm not very familiar with MeshWorks.)

> And likewise, I could take individual trees after opening them into 
> the program and combine them into a single object.  Right?

Yes, that's possible.

>   I'll study the trimesh code.  I guess what would be nice is to only 
> have the trimesh stored once and then specify that it is simply placed 
> in the world multiple times.  Is that on the right track?

That's different.  If you have multiple references to the same TriMesh, 
with different transforms, then it will save memory, but not help with 
speed.
--
<http://www.jwwalker.com/>

Re: Does the number of objects matter?

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

James W. Walker wrote:

> On Jun 14, 2004, at 9:59 PM, Keith Wiley wrote:
>
>> Followup question if anyone doesn't mind.  Can I easily open a bunch 
>> of separate objects, and then combine collections of objects after 
>> opening them into a single object?  Can an entire static scene 
>> actually be coallesced into a single object from a collection of 
>> individual objects?
>
>
> Depends on what you mean by "object".  You can put a bunch of objects 
> into a group object, but that doesn't really buy you anything compared 
> to submitting the objects individually.   What does help is if you can 
> go down to the TriMesh level and combine some.  In order to be able to 
> merge TriMesh objects, they would need to have the same overall 
> attributes (color, texture, etc.).

Okay, I see.  So, if in Meshwork I create a tree, then copy and paste it next to the original tree so I have two separate trees, with totally unconnected vertices, I can save the entire thing not only as a group (which doesn't do much) but as a single "object" even though it is clearly physically two separate objects.

And likewise, I could take individual trees after opening them into the program and combine them into a single object.  Right?  I'll study the trimesh code.  I guess what would be nice is to only have the trimesh stored once and then specify that it is simply placed in the world multiple times.  Is that on the right track?


________________________________________________________________________
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: Does the number of objects matter?

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

On Jun 14, 2004, at 9:59 PM, Keith Wiley wrote:

> Followup question if anyone doesn't mind.  Can I easily open a bunch 
> of separate objects, and then combine collections of objects after 
> opening them into a single object?  Can an entire static scene 
> actually be coallesced into a single object from a collection of 
> individual objects?

Depends on what you mean by "object".  You can put a bunch of objects 
into a group object, but that doesn't really buy you anything compared 
to submitting the objects individually.   What does help is if you can 
go down to the TriMesh level and combine some.  In order to be able to 
merge TriMesh objects, they would need to have the same overall 
attributes (color, texture, etc.).
--
<http://www.jwwalker.com/>

Re: Does the number of objects matter?

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

Wow!  I downloaded your multibox demos and ran them.  The merged version 
is impressive to say the least.  I am not even remotely a Quesa pro by 
any stretch, but I can hack on it pretty well.  I am unsure on the 
following point.  When you merged all those boxes together (I'm not even 
sure what that means since the GeomTest code appears to create and add 
all the boxes to one group to begin with, so I'm confused on that 
point), was that something you could do in code, on the fly at runtime?  
Or could you only do it by externally constructing a 3DMF file of the 
merged boxes?

I ask because for the game I am presently working on, just beginning 
actually, it would be nice to merge large groups of static similar 
objects (there will be a forest with numerous trees, kinda like Nanosaur 
II I suppose), but it would need to be done at runtime from a set of 
tree objects that are opened.  I can't very well make a 3DMF file of the 
entire forest.  It would defeat the entire point of modularity.  :-)

I would love to know how to merge objects in code, if that can be done.  
Like I said,  I'm not quite clear on what merging objects is all about 
in the first place, but I can certainly appreciate the results you showed.

Thanks.

James W. Walker wrote:

> On Jun 14, 2004, at 6:24 PM, Keith Wiley wrote:
>
>> The question is, is either of these scenes more or less complex to 
>> render...in terms of speed of course?  Which would yield a higher 
>> framerate, if there is a difference?
>
>
> I posted a relevant message just yesterday, in the thread "Re: Quesa - 
> "Most Wanted" list".   Short answer, yes it matters, a few big objects 
> is faster than a lot of little objects.


________________________________________________________________________
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: Does the number of objects matter?

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

Sorry, new to the list (well, back from a year or so hiatus during which 
I wasn't doing much 3D programming).

That was my prediction, fewer larger is faster than more smaller.

Followup question if anyone doesn't mind.  Can I easily open a bunch of 
separate objects, and then combine collections of objects after opening 
them into a single object?  Can an entire static scene actually be 
coallesced into a single object from a collection of individual objects?

I'll puruse the relevant threads in the archives.  Thanks for the pointer.

James W. Walker wrote:

> On Jun 14, 2004, at 6:24 PM, Keith Wiley wrote:
>
>> The question is, is either of these scenes more or less complex to 
>> render...in terms of speed of course?  Which would yield a higher 
>> framerate, if there is a difference?
>
>
> I posted a relevant message just yesterday, in the thread "Re: Quesa - 
> "Most Wanted" list".   Short answer, yes it matters, a few big objects 
> is faster than a lot of little objects.

________________________________________________________________________
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: strange texture animation behavior

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

Hmmm, well, it's slightly reassuring to know that the problem is 
"public".  What would be more assuring would be an understanding of why 
it's doing this, and the creme de la creme would be a solution of 
course.  :-)

Thanks.  I'll just have to work around it until the situation becomes 
clearer.

Lane Roathe wrote:

>Nanosaur for Windows exhibits this very problem... although I think in
>the latest version of Quesa this particular problem may have been solved
>for Nano. (other problems replaced it).
>
>At one point I had removed this feature from Nanosaur because of the UV
>scrolling problems. Not sure if I ever put it back in actually ...
>  
>
________________________________________________________________________
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: Does the number of objects matter?

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

On 14-Jun-04, at 9:24 PM, Keith Wiley wrote:

> Say I have a scene with some number of objects in it.  Say this scene 
> can be represented in two different ways.  One is a single huge 
> object, and another is a bunch of little objects that visually appear 
> identical to the large object...
>
> Assume the number of vertices, edges, what not is absolutely identical.

It will almost always be more efficient to use fewer objects. This was 
discussed in detail very recently: 
<http://sourceforge.net/mailarchive/message.php?msg_id=8703543>

Frank.

Re: Does the number of objects matter?

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

On Jun 14, 2004, at 6:24 PM, Keith Wiley wrote:

> The question is, is either of these scenes more or less complex to 
> render...in terms of speed of course?  Which would yield a higher 
> framerate, if there is a difference?

I posted a relevant message just yesterday, in the thread "Re: Quesa - 
"Most Wanted" list".   Short answer, yes it matters, a few big objects 
is faster than a lot of little objects.
--
<http://www.jwwalker.com/>

Re: strange texture animation behavior

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

Nanosaur for Windows exhibits this very problem... although I think in
the latest version of Quesa this particular problem may have been solved
for Nano. (other problems replaced it).

At one point I had removed this feature from Nanosaur because of the UV
scrolling problems. Not sure if I ever put it back in actually ...

on Mon, Jun 14, 2004 Keith Wiley may have said:

>I am doing a simple texture "animation" by scrolling the UV coordinates 
>of a texture, exactly as per the Nanosaur public code.  I got it to work 
>without a problem, except there's a problem.  I have a couple models in 
>the world right now.  It's a test world so it's not very interesting, 
>just a place to screw around.  The texture and object in question 
>animate perfectly, a really cheap looking waterfall which I will make 
>fancier when the time comes.  Here's the thing.  Some of the other 
>objects in the world are displaying texture scrolling as well, but yet 
>some other objects aren't.  I didn't want anything to scroll that I 
>don't explicitly designate as such of course.  I can't figure out why 
>some unintended objects and textures are scrolling while others remain 
>normal.
>
>Bear in mind that each of these objects came from a separate 3DMF file 
>with its own texture and basically totally separate from all the other 
>models in every way I can imagine.
>
>What could possibly cause this?  Here's my code.  It's ridiculously 
>simple, because as far as I can tell, scrolling the texture isn't very 
>hard.  (This code is written with the Queeg framework, with necessary 
>accessors added to the associated classes, and the function below is 
>called from the Queeg Update function).
>
>Any help appreciated.  Thanks.
>
>void AnimateWaterfallTexture()
>{
>    TQ3Matrix3x3 uvTransformMatrix;
>    Q3Matrix3x3_SetTranslate(&uvTransformMatrix, gH, gV);
>    gH += 0;
>    gV -= .003;
>   
>    QGTriMesh* triMesh = gWaterfall->GetFirstTriMesh();
>   
>    TQ3TriMeshData triMeshData;
>    triMeshData = triMesh->GetTriMeshData();
>   
>    TQ3SurfaceShaderObject    shader;
>   
>    if (triMeshData.triMeshAttributeSet)
>    {
>        if (Q3AttributeSet_Contains(triMeshData.triMeshAttributeSet, 
>kQ3AttributeTypeSurfaceShader))
>        {
>            Q3AttributeSet_Get(triMeshData.triMeshAttributeSet, 
>kQ3AttributeTypeSurfaceShader, &shader);
>            Q3Shader_SetUVTransform(shader, &uvTransformMatrix);
>            Q3Object_Dispose(shader);
>        }
>    }
>}


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
Life is cheap, but the accessories will break you.

Does the number of objects matter?

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

Say I have a scene with some number of objects in it.  Say this scene can be represented in two different ways.  One is a single huge object, and another is a bunch of little objects that visually appear identical to the large object (think a single tree vs a trunk and a bunch of branches, and a bunch of leaves, all separate objects by placed in logical spatial correspondance to one another so as to build a tree.

Assume the number of vertices, edges, what not is absolutely identical.

Assume for the moment that I figure out how to make objects with the same texture share that texture in RAM and/or VRAM instead of each having their own individual copies (I'm not sure how to do this yet, but assume this is how it's done).

The question is, is either of these scenes more or less complex to render...in terms of speed of course?  Which would yield a higher framerate, if there is a difference?

Just wondering if I need to take this sort of thing into account when designing my system or if I can go either way without too much worry one way or the other.

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
________________________________________________________________________