sgl-dev

Re: [sgl-dev] Contribution to SGL?

[Scott a. L. M. <mcm...@ya...>]

It appears that we don't have the time necessary to
help with your needs.  At the same time the changes to
upgrade to the latest generation of compilers is
sorely needed.  I would definitely entertain the idea
of adding one of your developers to the sgl project so
that you can check changes directly into the
repository.

What platforms (hardware/OS/compilers) do you have
access to in order make sure things build and work on
them.

Regards,
scott

--- Erwann HOUZAY <erw...@ig...> wrote:

> Hi all;
> 
>  
> 
> I don’t have any info about our possible
> contribution to the SGL project….
> 
>  
> 
> We have rebuild all the Mirosoft Visual project
> files (including test
> programs). I’ve also done a simple automake autoconf
> for the main sgl
> modules. I can’t include inside the modules with
> dependencies like sglqt,
> sgflt and sglCal. (powerfull but quite hard tool!!).
> All works with XP, even
> the tests :-)
> 
>  
> 
> I’ve also modified a file in sglmd3 due to a
> conversion problem which create
> an error with gcc.
> 
>  
> 
> I’ve also modified testVec.cpp and testMat.cpp in
> order to compile them.
> 
>  
> 
> An other member of my laboratory has also removed
> some simple warning which
> appears whith gcc-4
> 
>  
> 
> What about comiting all this work? We are seriously
> thinking about an active
> participation to SGL. We are about twenty developers
> here. As we have
> started to use SGL, I’m sure we probably add
> interesting things and remove
> some possible bugs. For example, we are thinking
> about a Collada I/O for SGL
> in order to be compatible with google earth to
> include the results of our
> reconstructions in there real locations. Also we
> care about multi-plateform
> portability. We have currently MAC/LINUX/WINDOWS
> supported.
> 
>  
> 
> I think a common CVS developer access for all of y
> Lab should be a good
> idea. Before all commits, we will advise!!!! 
> 
>  
> 
> We are successfully using SGL for our works with
> wxWindows. It’s nice,
> efficient and very easy to use. 
> 
>  
> 
> Thanks for your answer (and also for the great job
> you’ve done!!)
> 
>  
> 
>  
> 
> ---------------------------------------------
> 
> Below a question from one of our developers:
> 
>  
> 
> I am trying to do some kind of video player with
> SGL. To do that, I created
> some triangles strip, and set a sglTexture2D to that
> triangle set.
> 
> I try then to set dynamically some jpeg picture to
> this texture, and I would
> like to keep image data in memory to have a quick
> SetImage if source image
> have already been loaded from disk. To do this I
> store pDest into a map,
> where key is frame number. When I reach a frame
> which image is already
> loaded from disk (in the map) I set it directly. But
> it seems that SGL
> release this data. 
> 
> How could I succeed keeping data into main memory ?
> Should I do a copy of
> this picture before binding ? In this case, canI
> keep a compressed copy ?
> Thanks for help.
> 
> cf : see my Update code below (test succeeds if data
> not loaded, fails if
> already seen)
> 
> if (it == m_imageMap.end()) {
> 
> void *image = sglImageLoader::loadImage(FilePath,
> width, height, format,
> type, nbbytes);
> 
> sglNoRefDataPtr * p = new sglNoRefDataPtr(image);
> 
> pTex->setImage(p,format, type, width, height, false,
> nbbytes);
> 
> sglDataPtr * pDest = NULL;
> 
> pTex->getImage(pDest,format,type,width, height,
> border,nbbytes);
> 
> pair< imageMap::iterator, bool > pr =
>
m_imageMap.insert(imageMap::value_type(m_pGeoTraj->GetCurrentNode().m_iRecor
> dID, pDest));
> 
> }
> 
> else 
> 
> {
> 
> sglDataPtr *old_image;
> 
> bool border;
> 
> /// Get the values of the parameters used in
> setImage.
> 
> pTex->getImage(old_image,format,type,width, height,
> border,nbbytes);
> 
> sglNoRefDataPtr * pDest = it->second;
> 
> pTex->setImage(pDest,format, type, width, height,
> false, nbbytes);
> 
> }
> 
>  -------------------------------
> 
> Erwann HOUZAY
> 
> Chargé d'études et de Développement
> 
>  Laboratoire MATIS-Institut Géograhique National
> 
> 2-4 Av. Pasteur, 94165 St. Mandé cedex, France
> 
> tel:7582  Bureau: K 311 B
> 
>  
> 
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Re: [sgl-dev] sgl-dev Digest, Vol 2, Issue 3

[Larry E. R. <ra...@si...>]

sgl...@li... wrote:
> Send sgl-dev mailing list submissions to
> 	sg...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/sgl-dev
> or, via email, send a message with subject or body 'help' to
> 	sgl...@li...
>
> You can reach the person managing the list at
> 	sgl...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sgl-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: A stable release? (Rene Horn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Oct 2006 17:48:56 -0500
> From: "Rene Horn" <the...@gm...>
> Subject: Re: [sgl-dev] A stable release?
> To: "SGL Development Mailing List" <sg...@li...>
> Message-ID:
> 	<b8e...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The current stable release doesn't compile on gcc 4.1.  There was a
> patch applied to CVS that probably should have been backported, but
> that didn't seem to happen.
>
> Rene
>
> On
Can you post some of the errors? I've had no problems with 3.4.5, I'm 
curious what caused issues in 4.1

Re: [sgl-dev] A stable release?

[Rene H. <the...@gm...>]

The current stable release doesn't compile on gcc 4.1.  There was a
patch applied to CVS that probably should have been backported, but
that didn't seem to happen.

Rene

On 10/19/06, Michael Morrison <mic...@me...> wrote:
> The current release is pretty stable.  Are you having specific issues you
> would like to discuss?
>
> ----- Original Message -----
> From: "Rene Horn" <the...@gm...>
> To: "SGL Dev" <sg...@li...>
> Sent: Tuesday, October 17, 2006 8:52 PM
> Subject: [sgl-dev] A stable release?
>
>
> > Will there be a stable release any time soon?  The current ones are
> > over two years old.
> >
> > Rene
> > --
> > the...@gm..., rh...@sd...,
> > ho...@uw... (UW-Oshkosh email address),
> > http://rhorn.unixcab.org - a bunch of experimental stuff
> > SDF Public Access UNIX System - http://sdf.lonestar.org
> >
> > Jay Leno in response to Colin Powell's deadline for an Iraqi
> > constitution:
> > "They can take ours.  After all, we aren't using it..."
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > sgl-dev mailing list
> > sg...@li...
> > https://lists.sourceforge.net/lists/listinfo/sgl-dev
> >
> >
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sgl-dev mailing list
> sg...@li...
> https://lists.sourceforge.net/lists/listinfo/sgl-dev
>


-- 
the...@gm..., rh...@sd...,
ho...@uw... (UW-Oshkosh email address),
http://rhorn.unixcab.org - a bunch of experimental stuff
SDF Public Access UNIX System - http://sdf.lonestar.org

Jay Leno in response to Colin Powell's deadline for an Iraqi
constitution:
"They can take ours.  After all, we aren't using it..."

Re: [sgl-dev] A stable release?

[Michael M. <mic...@me...>]

The current release is pretty stable.  Are you having specific issues you
would like to discuss?

----- Original Message ----- 
From: "Rene Horn" <the...@gm...>
To: "SGL Dev" <sg...@li...>
Sent: Tuesday, October 17, 2006 8:52 PM
Subject: [sgl-dev] A stable release?


> Will there be a stable release any time soon?  The current ones are
> over two years old.
>
> Rene
> -- 
> the...@gm..., rh...@sd...,
> ho...@uw... (UW-Oshkosh email address),
> http://rhorn.unixcab.org - a bunch of experimental stuff
> SDF Public Access UNIX System - http://sdf.lonestar.org
>
> Jay Leno in response to Colin Powell's deadline for an Iraqi
> constitution:
> "They can take ours.  After all, we aren't using it..."
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sgl-dev mailing list
> sg...@li...
> https://lists.sourceforge.net/lists/listinfo/sgl-dev
>
>

[sgl-dev] A stable release?

[Rene H. <the...@gm...>]

Will there be a stable release any time soon?  The current ones are
over two years old.

Rene
-- 
the...@gm..., rh...@sd...,
ho...@uw... (UW-Oshkosh email address),
http://rhorn.unixcab.org - a bunch of experimental stuff
SDF Public Access UNIX System - http://sdf.lonestar.org

Jay Leno in response to Colin Powell's deadline for an Iraqi
constitution:
"They can take ours.  After all, we aren't using it..."

Re: [sgl-dev] Compilation of SGL with gcc 4 (4.1.0)

[Lambert, L. <FHWA> <Luk...@fh...>]

Your update does indeed fix those compilation errors, but now the build
of SGL gets hung up on others.  In sgl/sglmd3/md3file.cpp the code
breaks everywhere the return value of fail() (an MD3File*) is cast to an
int.  This could be due I am compiling with the m64 flag.  My current
hack around this is to change the return type of fail to an int, because
it only ever returns the literal constant 0.  The function md3Open must
subsequently be modified to always return 0 on failure (which fits,
fail() would only ever return 0 anyway).  The impact of these changes
should be minor if anything.  There may still be more compilation
errors, but right now I'm hung up on some glut linker issue and
libsgltxp.so.  I will keep the group posted.

--
Luke Lambert

-----Original Message-----
From: sgl...@li...
[mailto:sgl...@li...] On Behalf Of Thomas
Stimson
Sent: Tuesday, June 06, 2006 1:38 AM
To: sg...@li...
Subject: Re: [sgl-dev] Compilation of SGL with gcc 4 (4.1.0)

On Wed, May 24, 2006 at 12:47:41PM -0400, Lambert, Luke <FHWA> wrote:
> I've run into a snag while compiling SGL with gcc 4 [4.1.0 20060304
(Re
> Hat 4.1.0-3) specifically].  I get a number of errors in
> sglTriStripper.hpp.  It seems gcc no longer permits a list_iterator
> (sglTriList<T>::iterator defined in sglTriStruct.hpp, line 65) to be
> tested with !=3D int, or assigned NULL.  Examples of this are on (but
not
> limited to) lines 548, 618 (!=3D test), and 325 (assignment to null) =
in
> sglTriStripper.hpp.  I'd appreciate if someone could suggest a
> work-around that would honor what the original code intended.

I've commited a fix for this.  Hopefully, the fix won't break the
other compilers.  I only tested a couple.

--=20
   Thomas Jay Stimson
   Th...@St...


_______________________________________________
sgl-dev mailing list
sg...@li...
https://lists.sourceforge.net/lists/listinfo/sgl-dev

Re: [sgl-dev] Compilation of SGL with gcc 4 (4.1.0)

[Thomas S. <Th...@St...>]

On Wed, May 24, 2006 at 12:47:41PM -0400, Lambert, Luke <FHWA> wrote:
> I've run into a snag while compiling SGL with gcc 4 [4.1.0 20060304 (Re
> Hat 4.1.0-3) specifically].  I get a number of errors in
> sglTriStripper.hpp.  It seems gcc no longer permits a list_iterator
> (sglTriList<T>::iterator defined in sglTriStruct.hpp, line 65) to be
> tested with != int, or assigned NULL.  Examples of this are on (but not
> limited to) lines 548, 618 (!= test), and 325 (assignment to null) in
> sglTriStripper.hpp.  I'd appreciate if someone could suggest a
> work-around that would honor what the original code intended.

I've commited a fix for this.  Hopefully, the fix won't break the
other compilers.  I only tested a couple.

-- 
   Thomas Jay Stimson
   Th...@St...

[sgl-dev] sgl commit

[Thomas S. <st...@us...>]

Update of /cvsroot/sgl/sgl/sgldb
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv9155

Modified Files:
	sglTriStripper.hpp sglLineStripper.hpp sglTriStruct.hpp 
Log Message:
Fixed compiler errors with g++ 4.1.

[sgl-dev] Compilation of SGL with gcc 4 (4.1.0)

[Lambert, L. <FHWA> <Luk...@fh...>]

I've run into a snag while compiling SGL with gcc 4 [4.1.0 20060304 (Re
Hat 4.1.0-3) specifically].  I get a number of errors in
sglTriStripper.hpp.  It seems gcc no longer permits a list_iterator
(sglTriList<T>::iterator defined in sglTriStruct.hpp, line 65) to be
tested with !=3D int, or assigned NULL.  Examples of this are on (but =
not
limited to) lines 548, 618 (!=3D test), and 325 (assignment to null) in
sglTriStripper.hpp.  I'd appreciate if someone could suggest a
work-around that would honor what the original code intended.

=20

--

Luke Lambert

Luk...@fh...

=20

[sgl-dev] Fwd: SUBJECT: SourceForge.net: CVS service offering changes

[Scott a. L. M. <mcm...@ya...>]

--- "SourceForge.net Team" <no...@so...>
wrote:

> From: "SourceForge.net Team"
> <no...@so...>
> To: mcm...@ya...
> Subject: SUBJECT: SourceForge.net: CVS service
> offering changes 
> Date: Thu, 11 May 2006 16:13:23 -0700 (PDT)
> 
> Greetings,
> 
> You are receiving this mail because you are a
> project admin for
> a SourceForge.net-hosted project. One of our primary
> services,
> CVS, suffered a series of interrelated, critical
> hardware failures
> in recent weeks. We understand how frustrating this
> CVS outage
> must be to you and your users; however, our top
> priority remains
> preservation of the integrity of your data.
> 
> The series of CVS hardware failures prompted us to
> expedite the
> deployment of planed improvements to our CVS
> infrastructure,
> drawing upon much of the knowledge that we gained
> from our
> Subversion deployment. Our improved CVS service
> architecture,
> which we plan to deploy tomorrow afternoon
> (2006-05-12), will
> offer greater performance and stability and will
> eliminate several
> single points of failure.
> 
> The Site Status page (https://www.sf.net/docs/A04)
> will be
> updated as soon as the new infrastructure is rolled
> out. In the
> interim, please read the important information
> provided below
> to learn about how these changes will affect your
> project.
> 
> 
> Summary of changes, effective 2006-05-12:
> 
> 
> 1. Hostname for CVS service
> 
> Old: cvs.sourceforge.net
> 
> New: PROJECT_UNIX_NAME.cvs.sourceforge.net
> 
> This change will require new working copies to be
> checked out of all
> repositories (so control files in the working copy
> will point to the
> right place). We will be updating the instructions
> we supply, but
> instructions that your team has written within
> documentation, etc. will
> need to be updated.
> 
> cvs
>
-d:pserver:ano...@cv...:/cvsroot/gaim
> co gaim
> 
> would be changed to
> 
> cvs
>
-d:pserver:ano...@ga...:/cvsroot/gaim
> co gaim
> 
> 
> 
> 2. ViewCVS
> 
> We are moving from ViewCVS to its successor, ViewVC.
> ViewVC is
> currently in use for our Subversion service.
> 
> 
> 
> 3. Sync delay
> 
> Old: CVS pserver, tarballs and ViewCVS provided
> against a separate
> server which is a minimum of three hours behind
> developer CVS.
> 
> New: ViewVC will be provided against developer CVS
> (it will be current).
> CVS pserver will be provided against a secondary
> server (not developer
> server) with a maximum expected delay of two hours.
> 
> Follow-up work is planned (this infrastructure takes
> us 80% of the way)
> to essentially eliminate the sync delay.
> 
> 
> 
> 4. Read-only rsync service
> 
> As a new service offering, we are now providing
> read-only rsync access
> against developer CVS. This allows projects to
> efficiently make
> on-demand backups of their entire CVS repository.
> 
> All projects should be making regular backups of
> their CVS repository
> contents using this service.
> 
> 
> 
> 5. Nightly tarball service
> 
> Nightly tarball service is being dropped in lieu of
> read-only rsync
> service. Projects which currently depend on nightly
> tarballs for
> repository backups will need to begin using rsync to
> make a backup copy
> of their repository contents.
> 
> We see this as a major functional improvement. For a
> number of reasons,
> tarballs have fallen out of sync with the data in
> the repository at
> times in the past few years. Tarballs required a
> substantial amount of
> additional disk, and I/O to generate. The move to
> read-only rsync
> allows backups to be produced on-demand, with an
> update frequency chosen
> by the project.
> 
> 
> 
> 6. Points of failure
> 
> In the past, developer CVS service for all projects
> was provided from a
> single host. CVS pserver service was provided from
> individual backend
> heads based on a split of the data.
> 
> Under our new design, developer CVS and most of our
> CVS-related services
> are provided from one of ten CVS hosts (count
> subject to increase with
> growth). Each host is independent, and makes a
> backup copy of the
> repository data of another host (which is used to
> provide the pserver
> CVS service).
> 
> Failure of a single host will impact only the
> availability of data on
> that host. Since the data is split among a larger
> number of hosts, the
> size of data impacted by an individual host outage
> is substantially
> smaller, and the time required for us to restore
> service will be
> substantially shorter.
> 
> This rapid architecture change has been made
> possible specifically using
> the research we performed for our recent launch of
> Subversion service.
> We've applied our best practices, produced a
> substantial amount of
> internal documentation, and kept an eye toward
> maintainability.
> This effort has allowed us to deploy this new
> architecture quickly
> once hardware was received, and will permit us to
> quickly scale
> this service horizontally as growth and demand
> requires. 
> 
> 
> 
> Many other minor improvements have also been made to
> improve the service
> offering and make it less trouble-prone. The most
> important of which are
> listed above. For a full description of the new
> service offering, and
> for information on how to use the services described
> above, please refer
> to the site documentation for the CVS service after
> the service has been
> launched: https://www.sf.net/docs/E04
> 
> 
> Thank you,
> 
> The SourceForge.net Team 
> 
> .
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[sgl-dev] sgl commit

[Michael M. M. <mor...@us...>]

Update of /cvsroot/sgl/sgl/sglCal
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv354/sglCal

Added Files:
	Makefile README SubMesh.cpp SubMesh.h sglCalCoreModel.cpp 
	sglCalCoreModel.h sglCalModel.cpp sglCalModel.h testCal.cpp 
Log Message:
Files to allow use of Cal3d in SGL.

[sgl-dev] sgl commit

[Michael M. M. <mor...@us...>]

Update of /cvsroot/sgl/sgl/sglCal
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32409/sglCal

Log Message:
Directory /cvsroot/sgl/sgl/sglCal added to the repository

[sgl-dev] sgl commit

[Michael M. M. <mor...@us...>]

Update of /cvsroot/sgl/sgl/sgl
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6570

Modified Files:
	sgl.cpp sgl.h sglScene.cpp sglStatelet.cpp sglStatelet.hpp 
	sglVBO.hpp 
Log Message:
Added support for Nvidia's Primitive Restart.  Added support for VBO
mapBuffer and unmapBuffer.

[sgl-dev] sgl commit

[Thomas S. <st...@us...>]

Update of /cvsroot/sgl/sgl/sgl
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1759/sgl

Modified Files:
	sglBound.hpp 
Log Message:
Added missing virtual destructor.

[sgl-dev] Display Lists?

[Larry E. R. <ra...@si...>]

So we made an application using SGL that had multiple windows. In one 
window was scene A, in the other window was scene B. There was only 1 
OpenGL context between the 2 windows, so I figured I would be ok. 
However, if I remove something from scene B and add it to Scene A, it 
does not render. It is clearly there and if you print the scenegraph it 
shows up. So I figured this maybe had something to do with an internal 
list of compiled Display Lists or whatnot (just guessing).

I hacked sglDrawable and move the ::dirty(mask,all) function into the 
public interface. Now after I move the subtree from B to A, I do a 
recursive search for all sglDrawables and I set the eDLIST mask with 
all=true. Bingo, it works fine.

Anyone want to explain why that worked?

Is there a better solution than my kludge of setting the dirty bit on 
all the drawables?



-- 
This e-mail and any attachments may contain confidential and privileged 
information. If you are not the intended recipient, please notify the sender 
immediately by return e-mail, delete this e-mail and destroy any copies. Any 
dissemination or use of this information by a person other than the intended 
recipient is unauthorized and may be illegal. Unless otherwise stated, 
opinions expressed in this e-mail are those of the author and are not 
endorsed by the author's employer.

Re: [sgl-dev] eTRANSFORM_MATRIX statelet

[Thomas S. <Th...@St...>]

The order of the default statelets in sglScene does not matter.
The default statelets are passed into sglCull::initialize(), which
inserts them into it's own vector, ordered by type.

-- 
   Thomas Jay Stimson
   Th...@St...

On Tue, Aug 23, 2005 at 05:24:36PM -0600, Michael M. Morrison wrote:
> In the current code base the eTRANSFORM_MATRIX enumerant in
> sglStatelet::StateEnum appears after eSHADE_MODEL and before eTRANSPARENCY.
> However, in sglScene::createDefaultStatelets() sglTransparency is pushed
> right after sglShadeModel with no space in between for "transform matrix."
> And therefore the order in the two lists is different.
> 
>  
> 
> Since several places in the code (sglCurrState.cpp) etc reference a
> full_state->m_statelet vector using eTRANSFORM_MATRIX and eTRANSPARENCY, it
> seems that this should have been causing problems all along.  
> 
>  
> 
> If this is a problem, I am not sure where to put eTRANSFORM_MATRIX in the
> enumeration in sglStatelet.hpp because it doesn't appear in the default
> statelet vector anywhere.  Am I missing something?
> 
>  
> 
> -Mike
> 
>  
> 

RE: [sgl-dev] eTRANSFORM_MATRIX statelet

[Williams, J. <Jas...@fh...>]

It may still be a problem even if people aren't aware of it because they =
have not used the combination in ways which is very visible.  I would =
suggest creating a test case which should bring out an obvious symptom =
of the matrix transform contradiction.
=20
Jason.

-----Original Message-----
From: sgl...@li... =
[mailto:sgl...@li...]On Behalf Of Michael M. =
Morrison
Sent: Tuesday, August 23, 2005 6:25 PM
To: sg...@li...
Subject: [sgl-dev] eTRANSFORM_MATRIX statelet



In the current code base the eTRANSFORM_MATRIX enumerant in =
sglStatelet::StateEnum appears after eSHADE_MODEL and before =
eTRANSPARENCY.  However, in sglScene::createDefaultStatelets() =
sglTransparency is pushed right after sglShadeModel with no space in =
between for "transform matrix."  And therefore the order in the two =
lists is different.

=20

Since several places in the code (sglCurrState.cpp) etc reference a =
full_state->m_statelet vector using eTRANSFORM_MATRIX and eTRANSPARENCY, =
it seems that this should have been causing problems all along. =20

=20

If this is a problem, I am not sure where to put eTRANSFORM_MATRIX in =
the enumeration in sglStatelet.hpp because it doesn't appear in the =
default statelet vector anywhere.  Am I missing something?

=20

-Mike

=20

[sgl-dev] eTRANSFORM_MATRIX statelet

[Michael M. M. <mor...@si...>]

In the current code base the eTRANSFORM_MATRIX enumerant in
sglStatelet::StateEnum appears after eSHADE_MODEL and before eTRANSPARENCY.
However, in sglScene::createDefaultStatelets() sglTransparency is pushed
right after sglShadeModel with no space in between for "transform matrix."
And therefore the order in the two lists is different.

 

Since several places in the code (sglCurrState.cpp) etc reference a
full_state->m_statelet vector using eTRANSFORM_MATRIX and eTRANSPARENCY, it
seems that this should have been causing problems all along.  

 

If this is a problem, I am not sure where to put eTRANSFORM_MATRIX in the
enumeration in sglStatelet.hpp because it doesn't appear in the default
statelet vector anywhere.  Am I missing something?

 

-Mike

 

[sgl-dev] Fwd: SGL Mac Fix

[Scott M. <smc...@st...>]

Thanks...I am forwarding to the mailing list.

---- Original message ----
>Date: Sun, 14 Aug 2005 21:40:47 -0400
>From: Andy Turner <ajt...@gm...> 
>Subject: SGL Mac Fix  
>To: mcm...@us...
>
>Hi Scott, I recently grabbed the most recent cvs of SGL and compiled
>it on my Mac running 10.4.2 and there are some very minor changes I
>believe.
>
>1) I think you don't need to link cc_dynamic now, 
>2) the POSIX timers *still* aren't in OS X, however it seems as though
>the getSysTime function (line 94) in sglTimespec.cpp is getting
>compiled. I've filed a 'bug/feature request' with Apple to properly
>implement these (after talking with Jon Hubbard, head of the BSD group
>inside Apple)
>
>After making sure that block of code didn't run, and changing the lib,
>it built and ran fine.
>Andy
>
>-- 
>Andrew Turner
>ajt...@hi...        42.4266N x 83.4931W
>http://highearthorbit.com              Northville, Michigan, USA
>idealistic technocrat
>
>Photos - http://flickr.com/photos/ajturner
>Travel   - http://highearthorbit.com/projects/location/
--
Scott McMillan
SGL Home Page: http://sgl.sourceforge.net
DynaMechs Home Page: http://dynamechs.sourceforge.net

[sgl-dev] Texture State sorting and Optimizations

[Michael M. M. <mor...@si...>]

> 
> What happens if you add sglStatelet::eTEXTURE+4 to the sort order?
> That should enable sorting on the second texture unit, but I've never
> tested it much.  If I remember correctly, multi-texturing was added
> after the sorting mechanism, and I never really tested the two together.
> 

Adding sglStatelet::eTEXTURE+0, +4, +8, +12 appears to sort the scene by
texture units provided that they are also using consistent
sglMultiTextureStatelet's as well.

Having sorting implemented using pointers seems nice for the implementation
of the sorting algorithms, but puts the burden of allocating and caching
pointers for most state on the loader writer, unfortunately.

This is where an optimization traversal (like the pfdMakeShared stuff in
performer) would make sense.  It could look INSIDE of, for instance,
sglMaterials to see if the colors were all the same and unify them down to a
single material to facilitate state sorting.

Some time ago we began discussions about an optimization traversal.  Anyone
feel like resurrecting the discussions?

-Mike

RE: [sgl-dev] Performer equivalences

[Michael M. M. <mor...@si...>]

> Hi,
> I am trying to learn about sgl by porting a simulator/IG app from=20
> Performer to sgl.=A0 While I have been able to figure out many=20
> 'different ways of getting the same thing done' there are some
> Performer features that I cannot find sgl equivalents for.=A0 Perhaps
> I don't know where to look, (maybe even on the 'todo list' :-)
> =A0
> 1) pfDrawBins - Performer has this facility to divvy up geometry
> into user ordered containers.=A0 I believe the closest sgl equivalent
> are sglDrawablePools, but I can only find automatic sorting to
> 'opaque' and 'transparent'.=A0 Is user differentiation of geometry
available?

Drawable pools happen automagically, as you have discovered.  Things are
added to the transparency bin (and therefore sorted) if they contain the
sglTransparency statelet.  Under certain circumstances, like when a
MultiSample visual is available, the transparency bin is actually not =
sorted
as the MSALPHA_TO_COVERAGE mask is set to allow multisampling to draw =
the
transparency correctly.  This is covered in more detail in the
sglTransparency statelet docs.

There is also an sglOrderdGroup:

An sglOrderedGroup node is a specialized group that ensures that the
subtree of child i is rendered before the subtree of i+1.  This node
disrupts
the state sorting process, but allows certain multipass algorithms to be
performed within a single draw traversal.  Other than this feature, this
node
behaves (and uses the interface for) sglGroup.
=A0
> 2) pfdMakeShared - reading in an OpenFlight model often results in
> many redundant states.=A0 Is there a facility to process a stable =
portion
> of a scene graph to eliminate unneeded state changes upon traversal?
>=A0

This is handled automatically in the OpenFlight loader.  It attempts to
reduce redundant state by state sorting and grouping.  Everything under =
an
Object node is state sorted, triangle stripped, and drawn using
sglMonoIndexedTriangleStripSets.  The more you have under your Object =
nodes,
the more optimal the scene will be.

There are currently no "global" optimiziers like you may find in other =
Scene
Graphs that will walk the scene and optimize it for you.  The output of =
the
VRML and OpenFlight loaders are pretty optimal as-is.  They will share
texture objects between like files, but that is the only state that is
shared globally.

-Mike

[sgl-dev] Performer equivalences

[DANIEL B. <BA...@aa...>]

Hi,
I am trying to learn about sgl by porting a simulator/IG app from=20
Performer to sgl.  While I have been able to figure out many=20
'different ways of getting the same thing done' there are some
Performer features that I cannot find sgl equivalents for.  Perhaps
I don't know where to look, (maybe even on the 'todo list' :-)
=20
1) pfDrawBins - Performer has this facility to divvy up geometry
into user ordered containers.  I believe the closest sgl equivalent
are sglDrawablePools, but I can only find automatic sorting to
'opaque' and 'transparent'.  Is user differentiation of geometry available?=

=20
2) pfdMakeShared - reading in an OpenFlight model often results in
many redundant states.  Is there a facility to process a stable portion
of a scene graph to eliminate unneeded state changes upon traversal?
=20
Thanks,
=20
--daniel

Re: [sgl-dev] Questions

[Thomas S. <Th...@St...>]

On Wed, Jun 15, 2005 at 06:06:26PM -0600, Michael M. Morrison wrote:
> 
> In sglCurrState.cpp sglCurrState::drawGeometry there is a "glColor4f" call
> right before the glCallList or drawable->drawImmediate.  Is there a reason
> for this?  The colors are compiled into the display list as far as I can
> tell.

I'm not completely sure about this one.  I think it has something to
do about ensuring the default color is white if no color is supplied
by the drawable.  This might have been for compatibilty with performer.


> 
> Setting the sort order to be eTEXTURE will sort the scene by texture, but
> only by the primary texture.  If there are multiple textures assigned to the
> drawable, it will continually re-apply the state every time before issuing
> the glCallList.  For example:
> 
> [.] 
> 
> The two lists above were both built with the same
> sglTexture2D/sglTextureCubeMap maps, but different sglMultiTextureStatelets.
> Although, there doesn't seem to be a way to sort by "multi-texture
> statelets."

What happens if you add sglStatelet::eTEXTURE+4 to the sort order?
That should enable sorting on the second texture unit, but I've never
tested it much.  If I remember correctly, multi-texturing was added
after the sorting mechanism, and I never really tested the two together.


-- 
   Thomas Jay Stimson
   Th...@St...

[sgl-dev] Questions

[Michael M. M. <mor...@si...>]

 

I have been doing some profiling with "gDEBugger" from www.gremedy.com
<http://www.gremedy.com/>  and have found a couple things I have questions
about:

 

In sglCurrState.cpp sglCurrState::drawGeometry there is a "glColor4f" call
right before the glCallList or drawable->drawImmediate.  Is there a reason
for this?  The colors are compiled into the display list as far as I can
tell.

 

Setting the sort order to be eTEXTURE will sort the scene by texture, but
only by the primary texture.  If there are multiple textures assigned to the
drawable, it will continually re-apply the state every time before issuing
the glCallList.  For example:

 

[.]

 

glActiveTexture(GL_TEXTURE0) 
glDisable(GL_TEXTURE_1D) 
glDisable(GL_TEXTURE_2D)

glBindTexture(GL_TEXTURE_CUBE_MAP, 6) [Context 1 - Texture 6:] 
glEnable(GL_TEXTURE_CUBE_MAP) 
glActiveTexture(GL_TEXTURE0) 
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 7681) 
glTexEnvf(GL_TEXTURE_FILTER_CONTROL, GL_TEXTURE_LOD_BIAS, 0.00) 
glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, 0) 
glActiveTexture(GL_TEXTURE1) 
glDisable(GL_TEXTURE_1D) 
glDisable(GL_TEXTURE_CUBE_MAP) 
glBindTexture(GL_TEXTURE_2D, 20) [Context 1 - Texture 20:] 
glEnable(GL_TEXTURE_2D) 
glActiveTexture(GL_TEXTURE1) 
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 34160) 
glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, (0.00, 0.00, 0.00, 0.00)) 
glTexEnvf(GL_TEXTURE_ENV, GL_COMBINE_RGB, 34478.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_RGB_SCALE, 1.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_RGB, 5890.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND0_RGB, 768.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_RGB, 34168.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND1_RGB, 768.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_COMBINE_ALPHA, 8448.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_ALPHA_SCALE, 1.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_ALPHA, 5890.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, 770.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_ALPHA, 34168.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND1_ALPHA, 770.00) 
glTexEnvf(GL_TEXTURE_FILTER_CONTROL, GL_TEXTURE_LOD_BIAS, 0.00) 
glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, 0) 
glActiveTexture(GL_TEXTURE2) 
glDisable(GL_TEXTURE_1D) 
glDisable(GL_TEXTURE_CUBE_MAP) 
glBindTexture(GL_TEXTURE_2D, 21) [Context 1 - Texture 21:] 
glEnable(GL_TEXTURE_2D) 
glCallList(308) 



glActiveTexture(GL_TEXTURE0) 
glDisable(GL_TEXTURE_1D) 
glDisable(GL_TEXTURE_2D) 
glBindTexture(GL_TEXTURE_CUBE_MAP, 6) [Context 1 - Texture 6:] 
glEnable(GL_TEXTURE_CUBE_MAP) 
glActiveTexture(GL_TEXTURE1) 
glDisable(GL_TEXTURE_1D) 
glDisable(GL_TEXTURE_CUBE_MAP) 
glBindTexture(GL_TEXTURE_2D, 20) [Context 1 - Texture 20:] 
glEnable(GL_TEXTURE_2D) 
glActiveTexture(GL_TEXTURE1) 
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 34160) 
glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, (0.00, 0.00, 0.00, 0.00)) 
glTexEnvf(GL_TEXTURE_ENV, GL_COMBINE_RGB, 34478.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_RGB_SCALE, 1.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_RGB, 5890.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND0_RGB, 768.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_RGB, 34168.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND1_RGB, 768.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_COMBINE_ALPHA, 8448.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_ALPHA_SCALE, 1.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_ALPHA, 5890.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND0_ALPHA, 770.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_ALPHA, 34168.00) 
glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND1_ALPHA, 770.00) 
glTexEnvf(GL_TEXTURE_FILTER_CONTROL, GL_TEXTURE_LOD_BIAS, 0.00) 
glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, 0) 
glActiveTexture(GL_TEXTURE2) 
glDisable(GL_TEXTURE_1D) 
glDisable(GL_TEXTURE_CUBE_MAP) 
glBindTexture(GL_TEXTURE_2D, 21) [Context 1 - Texture 21:] 
glEnable(GL_TEXTURE_2D) 
glCallList(313) 

 

[.] 

 

The two lists above were both built with the same
sglTexture2D/sglTextureCubeMap maps, but different sglMultiTextureStatelets.
Although, there doesn't seem to be a way to sort by "multi-texture
statelets."

 

Any thoughts?  Is there a different way I should be building the state in
order to get more efficient scene sorting?

---
Michael M. Morrison
www.simcreator.com
Colorado: 970-377-1567/1537FAX
Michigan: 248-548-4876/6036FAX

This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this e-mail and destroy any copies. Any
dissemination or use of this information by a person other than the intended
recipient is unauthorized and may be illegal. Unless otherwise stated,
opinions expressed in this e-mail are those of the author and are not
endorsed by the author's employer.

 

[sgl-dev] sgl commit

[Michael M. M. <mor...@us...>]

Update of /cvsroot/sgl/sgl/testsgl
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16028

Modified Files:
	testShadowMap.cpp 
Log Message:
Updated to allow changing of shadow map size using up/dn arrow if FBO is
supported.