Thread: Re: [Algorithms] FW: [CsMain] Scene Graphs (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Stephen J B. <sj...@li...> - 2000-09-07 15:18:45
|
On Thu, 7 Sep 2000, Dave Eberly wrote: > From: "Stephen J Baker" <sj...@li...> > >The worst part of it is that without a standard SG, there is no > >way to promote the writing of generic 3D file loaders - which is > >something that's badly needed IMHO. > > Standardization is evil. Okay, a strong statement > to make :) Perhaps better is to point out that > standardization and innovation are in direct conflict. So you don't use OpenGL or D3D? You prefer to write your own renderer and forgo the advantages of (say) a GeForce2-Ultra? Not if you are into 'realtime' I suspect. I bet you *once* thought that a standardized renderer would stifle innovation - but it happened and you are still happily innovating away. You may once have been one of those people who did their own T&L rather than using OpenGL because it was stifling their innovation ... you don't hear much from those people anymore either. The deal is that this higher level of standardization doesn't prevent you from innovating - it just frees you from the bothersome details and lets you innovate at a higher level. Standardization *becomes* necessary the moment that hardware comes into the picture. With increasing need to put things into the memory of the graphics card - so will come the need to use a standardized scene graph API. There is no reason why a next-gen graphics card couldn't handle all the field of view culling and a bunch of other things automatically. ---- Science being insufficient - neither ancient protein species deficient. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: Dave E. <eb...@ma...> - 2000-09-07 18:53:02
|
From: "Stephen J Baker" <sj...@li...> > Standardization *becomes* necessary the moment that hardware > comes into the picture. With increasing need to put things > into the memory of the graphics card - so will come the need > to use a standardized scene graph API. I agree, as long as the standardized scene graph API is mine :) -- Dave Eberly eb...@ma... http://www.magic-software.com |
|
From: Kent Q. <ken...@co...> - 2000-09-14 18:38:15
|
Dave Eberly wrote: > > From: "Stephen J Baker" <sj...@li...> > >The worst part of it is that without a standard SG, there is no > >way to promote the writing of generic 3D file loaders - which is > >something that's badly needed IMHO. > > Standardization is evil. Okay, a strong statement > to make :) Perhaps better is to point out that > standardization and innovation are in direct conflict. Only in the area directly associated with the standard. Look at something like, oh, say, graphics cards. Back in the mid 80s, we had a whole raft of different card interfaces; if you wanted to write graphics code you had to write special drivers for each card you wanted to support. I made a business at that time out of writing graphics drivers. Over time, people started standardizing on the VGA. And then you could get out of the business of designing a software architecture that could write to every card on the market and you could start putting user features in instead. There were also a few people at that time who complained that the standards were evil because they stifled innovation. Then we went through a phase where compatibility with the VGA was vital. I then made a few bucks developing a VGA compatibility test suite for one of the magazines. Then we had new graphics cards with bitblt acceleration. The TI 94010 (did I get that number right?) and the like. I wrote some more drivers for Lotus 1-2-3...and then worked for Lotus to promote Lotus' toolkit so that people could write their own drivers. Getting the picture? When there aren't standards, people create and sell standardization systems. When there are standards, people test for compatibility with them. Standards are not only not evil, they're a necessary GOOD. What I think a lot of us are feeling is that the days of "look how many polygons *I* can shove down the pipeline" are numbered, and that we need to (or at least want to) start thinking at a higher level. Gimme a standard! Kent -- ----------------------------------------------------------------------- Kent Quirk | CogniToy: Intelligent toys... Game Architect | for intelligent minds. ken...@co... | http://www.cognitoy.com/ _____________________________|_________________________________________ |
|
From: Graham S. R. <gr...@se...> - 2000-09-06 19:27:14
|
Steve wrote, > There are dozens of OpenSourced scene graph API's out there. > Inventor becomes yet another. There are dozens of file formats > out there - .iv becomes yet another (and it's essentially just > VRML anyway - IIRC) Yes, quite true. I hear you and feel your pain. The same situation exists in the CAD world. Every solid modeler has its own native file format. CAD vendors don't want portability because their established customers would then have a choice, an option to choose a different tool without losing their past models, their past investment. Competition would become more price based---prices would have to come down and all hell would break loose. There is currently no good and robust way to pass parametric models back and forth among different CAD/modeling systems. The best you can do is to pass an instantaneous boundary rep model, and even that usually requires a human expert to resolve inconsistencies. I haven't had too much good experience with true standards, beyond, say, HTML. And I'll expand here at length on one of my recent BAD experiences with standards. We've just built a STEP translator for our Inventor-based model assembler. STEP is an international (ISO) standard data schema and file format for the storage and exchange of product data. And by product data I mean geometry describing the product, material properties and thicknesses, dependencies, analysis data (such as finite element models and results), electrical wiring, etc. It is sort of a replacement for IGES, among many other things. STEP is huge and after 15 years of development it is still experimental and incomplete. Pre-alpha. Our purpose was to support STEP AP 209 (an "application protocol" of STEP for finite element models and data). We use NASTRAN and ANSYS here, two finite element packages that have together the largest market share of all finite element packages. Their file formats are straightforward, even human readable. The STEP AP 209 file is a nightmare. In theory, it is human readable---it is text and the entity names appear to be meaningful at first glance. But there are so many many many different levels of abstraction and generalized terminology that it is just not possible to read it without going insane. And that would be OK----since really we would rather that computers read it----except that someone has to implement the translators and that means someone has to understand all these levels of abstraction. We are working with a STEP expert on this. Its their full time job to understand STEP and write translators and mappings. The STEP expert is having to consult with other STEP experts to interpret the standard. That would be OK, except that on numerous occasions *NONE* of the experts are able to come up with a concrete decision on what the standard actually intends. Even with our in-house expertise in finite element modeling, there are unanswered questions about how to model certain things. The documentation for this thing sucks. There are only a very very few examples out there. And the examples are *all* trivial ones, while our models are not trivial. We wanted to do some testing on our translator, to make sure we could read STEP files produced by another application and vice versa. That's the purpose, anyway, isn't it? So we contacted MSC Software to license their STEP translator for their MSC.Patran product. OK, we send them a purchase order, all seems well. They're very happy that we will send them money. We're happy too, until we get the code and try it. We export an AP 209 file from Patran and none of the AP 209 data is there. Its just NOT THERE. The documentation states it works, but clearly it does not. For 2 weeks, we fight with them. Turns out, they have multiple versions of the thing and no one is certain which one works. We are in contact with two other customers of MSC who have had similar problems getting working code. Eventually, somehow, thanks to calling MSC multiple times every day, we're able to get the "working" version of their translator. The version that supposedly had been conformance tested by MSC. The files that it exports are actually wrong, although they do contain the relevant information. They do not conform to the AP 209 schema. We have to manually modify the file to get it to conform. And we have to strip some information out, namely curved geometry data, since that is just completely bad---curves with knots at infinity, lost associativity, etc. Even MSC's own product cannot read it back in. MSC is one of the more active players in the committee that created the AP 209 part of the standard. And yet they cannot seem to produce a compliant AP 209 translator. If they can't get it right, how can we expect AP 209 to really work? So, in short, I just don't really believe that truly good standard file formats can emerge when they are designed by committee. I see more success in standard API's. The OpenGL approach is something I like. A top-notch company designs something that is simple, works damn well, and they run with it, making it available to the world, teaching the world how to use it, proving that it is good, superior, extending it over time----and building in an extensions mechanism. De facto standards, I believe, are much better than true standards, with very few exceptions. I'll give you another example. Anyone ever heard of PHIGS/PHIGS PLUS? Probably a good number of you, depending on how long you've been around doing 3D graphics. How many of you use it? What about you Playstation 2 developers? No? Windows? No? Macintosh? No? Linux? No? And yet...PHIGS and PHIGS PLUS are ISO standard APIs for 3D graphics. Graham Rhodes |
|
From: Akbar A. <sye...@ea...> - 2000-09-06 20:37:54
|
>The same situation exists in >the CAD world. Every solid modeler has its own native file format. CAD >vendors don't want portability because their established customers i know quite a few people that get paid decent money (better than most game modelers) to do just that. take old model's and convert them a new file format/program. imho i somewhat encourage this cause it opens up a lot of jobs. it's not like we are company owners. and i am sure nasa and raytheon can spare a few million ;) peace, akbar A. -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Graham S. Rhodes Sent: Wednesday, September 06, 2000 2:24 PM To: gda...@li... Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (long tangent rant on "standards") Steve wrote, > There are dozens of OpenSourced scene graph API's out there. > Inventor becomes yet another. There are dozens of file formats > out there - .iv becomes yet another (and it's essentially just > VRML anyway - IIRC) Yes, quite true. I hear you and feel your pain. The same situation exists in the CAD world. Every solid modeler has its own native file format. CAD vendors don't want portability because their established customers would then have a choice, an option to choose a different tool without losing their past models, their past investment. Competition would become more price based---prices would have to come down and all hell would break loose. There is currently no good and robust way to pass parametric models back and forth among different CAD/modeling systems. The best you can do is to pass an instantaneous boundary rep model, and even that usually requires a human expert to resolve inconsistencies. I haven't had too much good experience with true standards, beyond, say, HTML. And I'll expand here at length on one of my recent BAD experiences with standards. We've just built a STEP translator for our Inventor-based model assembler. STEP is an international (ISO) standard data schema and file format for the storage and exchange of product data. And by product data I mean geometry describing the product, material properties and thicknesses, dependencies, analysis data (such as finite element models and results), electrical wiring, etc. It is sort of a replacement for IGES, among many other things. STEP is huge and after 15 years of development it is still experimental and incomplete. Pre-alpha. Our purpose was to support STEP AP 209 (an "application protocol" of STEP for finite element models and data). We use NASTRAN and ANSYS here, two finite element packages that have together the largest market share of all finite element packages. Their file formats are straightforward, even human readable. The STEP AP 209 file is a nightmare. In theory, it is human readable---it is text and the entity names appear to be meaningful at first glance. But there are so many many many different levels of abstraction and generalized terminology that it is just not possible to read it without going insane. And that would be OK----since really we would rather that computers read it----except that someone has to implement the translators and that means someone has to understand all these levels of abstraction. We are working with a STEP expert on this. Its their full time job to understand STEP and write translators and mappings. The STEP expert is having to consult with other STEP experts to interpret the standard. That would be OK, except that on numerous occasions *NONE* of the experts are able to come up with a concrete decision on what the standard actually intends. Even with our in-house expertise in finite element modeling, there are unanswered questions about how to model certain things. The documentation for this thing sucks. There are only a very very few examples out there. And the examples are *all* trivial ones, while our models are not trivial. We wanted to do some testing on our translator, to make sure we could read STEP files produced by another application and vice versa. That's the purpose, anyway, isn't it? So we contacted MSC Software to license their STEP translator for their MSC.Patran product. OK, we send them a purchase order, all seems well. They're very happy that we will send them money. We're happy too, until we get the code and try it. We export an AP 209 file from Patran and none of the AP 209 data is there. Its just NOT THERE. The documentation states it works, but clearly it does not. For 2 weeks, we fight with them. Turns out, they have multiple versions of the thing and no one is certain which one works. We are in contact with two other customers of MSC who have had similar problems getting working code. Eventually, somehow, thanks to calling MSC multiple times every day, we're able to get the "working" version of their translator. The version that supposedly had been conformance tested by MSC. The files that it exports are actually wrong, although they do contain the relevant information. They do not conform to the AP 209 schema. We have to manually modify the file to get it to conform. And we have to strip some information out, namely curved geometry data, since that is just completely bad---curves with knots at infinity, lost associativity, etc. Even MSC's own product cannot read it back in. MSC is one of the more active players in the committee that created the AP 209 part of the standard. And yet they cannot seem to produce a compliant AP 209 translator. If they can't get it right, how can we expect AP 209 to really work? So, in short, I just don't really believe that truly good standard file formats can emerge when they are designed by committee. I see more success in standard API's. The OpenGL approach is something I like. A top-notch company designs something that is simple, works damn well, and they run with it, making it available to the world, teaching the world how to use it, proving that it is good, superior, extending it over time----and building in an extensions mechanism. De facto standards, I believe, are much better than true standards, with very few exceptions. I'll give you another example. Anyone ever heard of PHIGS/PHIGS PLUS? Probably a good number of you, depending on how long you've been around doing 3D graphics. How many of you use it? What about you Playstation 2 developers? No? Windows? No? Macintosh? No? Linux? No? And yet...PHIGS and PHIGS PLUS are ISO standard APIs for 3D graphics. Graham Rhodes _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
|
From: Graham S. R. <gr...@se...> - 2000-09-06 21:57:38
|
Akbar wrote, > i know quite a few people that get paid decent money (better than > most game modelers) to do just that. take old model's and convert > them a new file format/program. imho i somewhat encourage this > cause it opens up a lot of jobs. Good point. Yes, there is this positive side, I suppose. Its just frustrating when it takes weeks or months to convert a very complex model. I think it took 6 man-months to convert NASA's NGST model from NASTRAN to COMET-AR. And that model isn't that complex. > it's not like we are company owners. and i am sure nasa and raytheon can spare a few million ;) As an occasional project manager, I'm responsible for managing schedules and budgets. And it happens that I've been involved in this STEP project I described, where it is our *job* to automate the conversion process. Its just frustrating, really. And, as a stock holder, I *am* one of my company's owners! I could go on another complete rant about NASA and money. But that topic is not something for this forum. > peace, Yes, absolutely. Peace! Graham |
|
From: Akbar A. <sye...@ea...> - 2000-09-07 05:32:39
|
informing people notice: >I could go on another complete rant about NASA and money. recently raytheon and nasa are hiring/looking for programmers. but i'm not sure if the "game/graphics programmer" would do, imho- i'm pretty sure they are looking for people with "fluid simulation" experience , experience with "complicated stuff"; tossing around very large equations; occlusion culling does not count ;), etc.." iirc mostly embedded right now. but imho- it's not fun coding some "old-school" hardware just because it's "proven" and they can't take the risk of something crashing... <smiles> with games we are given an opportunity to run our code on the biggest baddest systems (excluding consoles) and you don't get more "next-gen tech" then that. we are also allowed a crash every now and then ;) and trust me, taking a step back is NO FUN. peace, akbar A. isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface Algorithms", by sutherland, sproull and schumacker that we use the eleventh algorithm ;) makes you really think -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Graham S. Rhodes Sent: Wednesday, September 06, 2000 4:54 PM To: gda...@li... Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (long tangent rant on "standards") Akbar wrote, > i know quite a few people that get paid decent money (better than > most game modelers) to do just that. take old model's and convert > them a new file format/program. imho i somewhat encourage this > cause it opens up a lot of jobs. Good point. Yes, there is this positive side, I suppose. Its just frustrating when it takes weeks or months to convert a very complex model. I think it took 6 man-months to convert NASA's NGST model from NASTRAN to COMET-AR. And that model isn't that complex. > it's not like we are company owners. and i am sure nasa and raytheon can spare a few million ;) As an occasional project manager, I'm responsible for managing schedules and budgets. And it happens that I've been involved in this STEP project I described, where it is our *job* to automate the conversion process. Its just frustrating, really. And, as a stock holder, I *am* one of my company's owners! I could go on another complete rant about NASA and money. But that topic is not something for this forum. > peace, Yes, absolutely. Peace! Graham _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
|
From: Graham S. R. <gr...@se...> - 2000-09-07 14:02:37
|
A followup "informing people" notice: Akbar wrote, > recently raytheon and nasa are hiring/looking for programmers. > > but i'm not sure if the "game/graphics programmer" would do, > imho- i'm pretty sure they are looking for people with "fluid simulation" > experience > , experience with "complicated stuff"; tossing around very large > equations; > occlusion culling does not count ;), etc.." The folks we work with at Langley have actually been trying to hire. They were looking for people with a Master's degree in either engineering or CS, but with fairly strong experience in *both* graphics and engineering. Having just experience in graphics was decided to be not enough, since the project managers are overbooked and wouldn't possibly have time to tutor on engineering mechanics and other things that are absolutely required to do the work. The other issue is this. NASA civil servant positions pay government salary levels, which seem to be quite a bit less than commercial salaries for s/w developers. The folks at Langley did find just a *few* people who met the requirements, but those people, recent graduates as it happens, were looking for starting salaries in the $70K range. And it happens that $70K is more than the task leader doing the hiring makes (as I was told). And he's been at NASA for quite a number of years now, has a Ph.D in engineering and a bit of experience with graphics and VR. Time to get off this tangent. Graham |
|
From: Stephen J B. <sj...@li...> - 2000-09-07 13:18:36
|
On Wed, 6 Sep 2000, Graham S. Rhodes wrote: > Steve wrote, > > > There are dozens of OpenSourced scene graph API's out there. > > Inventor becomes yet another. There are dozens of file formats > > out there - .iv becomes yet another (and it's essentially just > > VRML anyway - IIRC) > > Yes, quite true. I hear you and feel your pain. The same situation exists in > the CAD world. Every solid modeler has its own native file format. CAD > vendors don't want portability because their established customers would > then have a choice, an option to choose a different tool without losing > their past models, their past investment. Competition would become more > price based---prices would have to come down and all hell would break loose. Yes - but I'm not talking about standardizing file formats. If we had a scene graph API was some kind of a standard - then loaders for a huge variety of files formats could be built for it. <snipped story of STEP - which sound PAINFUL!> > So, in short, I just don't really believe that truly good standard file > formats can emerge when they are designed by committee. I see more success > in standard API's. The OpenGL approach is something I like. A top-notch > company designs something that is simple, works damn well, and they run with > it, making it available to the world, teaching the world how to use it, > proving that it is good, superior, extending it over time----and building in > an extensions mechanism. De facto standards, I believe, are much better than > true standards, with very few exceptions. Although - OpenGL is the direct descendent of IrisGL - which was a one off ad'hoc API that grew in a rather ugly way. OpenGL's design was essentially a major cleanup of something that had evolved over a lot of years. I agree that ad'hoc standards are a good thing - but there comes a point where they have to be formalized and taken over by a committee to stablise them. > I'll give you another example. Anyone ever heard of PHIGS/PHIGS PLUS? Yep. > Probably a good number of you, depending on how long you've been around > doing 3D graphics. How many of you use it? What about you Playstation 2 > developers? No? Windows? No? Macintosh? No? Linux? No? And yet...PHIGS and > PHIGS PLUS are ISO standard APIs for 3D graphics. PHIGS *was* a useful standard in it's day - it's just been obsoleted by the advent of fast, cheap 3D hardware. No standard lasts forever - which is why we are not all writing Algol'60 or FORTRAN IV. ---- Science being insufficient - neither ancient protein species deficient. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: Graham S. R. <gr...@se...> - 2000-09-07 14:11:18
|
Steve wrote, > I agree that ad'hoc standards are a good thing - but there comes a point > where they have to be formalized and taken over by a committee to stablise > them. I agree with you. OpenGL has certainly benefited from the approach you suggest. What bothers me is things that are built by committee from the ground up. > PHIGS *was* a useful standard in it's day - it's just been obsoleted by > the advent of fast, cheap 3D hardware. I think there actually was something called "Full PHIGS" or "Complete PHIGS" that came out around 1997 that was a bit more competitive in terms of capability. But to be honest I hadn't even heard of this incarnation until yesterday when I did a search to find out where PHIGS was at these days. > No standard lasts forever - which is why we are not all writing Algol'60 > or FORTRAN IV. I agree with you statement absolutely. But lasting forever is the *purpose* of a lot of true standards, and this purpose leads to their complexity and sometimes downfall. STEP, which I discussed, is designed to allow aircraft and automobile manufactures archive their complete design histories for 100 years. Not 5 years or 10 years. 100 years. And that is also the problem with true standards, in some cases. They are sometimes built for archival purposes, not practical day-to-day use. Enough of this nonsense! On to more important discussions! Graham Rhodes |
|
From: Stephen J B. <sj...@li...> - 2000-09-07 15:33:58
|
On Thu, 7 Sep 2000, Graham S. Rhodes wrote: > > I agree that ad'hoc standards are a good thing - but there comes a point > > where they have to be formalized and taken over by a committee to stablise > > them. > > I agree with you. OpenGL has certainly benefited from the approach you > suggest. What bothers me is things that are built by committee from the > ground up. Yes. Absolutely. Who wants to program in Ada when there is C++ - the US govt had to pass laws to force people to use it! Give me the work of two or three smart people any day. I had hoped that OpenGL++ would have worked out that way - since it would clearly have been a linear descendent of a number of other SGI scene-graph API's (notably the Cosmo scene graph and Performer) in just the same way that OpenGL was a descendent of IrisGL. Those scene graph API's have worked out pretty well but are in need of standardization/cleanup/portability effort just as IrisGL was. OpenGL++ might even have gotten there if the Fahrenheit nonense hadn't "hijacked" the standard *and* all the experienced people at SGI who were working on it. > > No standard lasts forever - which is why we are not all writing Algol'60 > > or FORTRAN IV. > > I agree with you statement absolutely. But lasting forever is the *purpose* > of a lot of true standards.... The formulators of a standard may like to imagine that to be the case - but it's naive. Nobody can predict what computers will be like in 10 years time - and to attempt to define a standard that'll last even 15 years is pushing it. > Enough of this nonsense! On to more important discussions! Indeed. We are way off-topic. ---- Science being insufficient - neither ancient protein species deficient. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: Ko, M. <MAN...@ca...> - 2000-09-06 18:37:28
|
Now there isn't. But you should be familiar with Performer and Fahrenheit as
a start. Otherwise you are in a huge hole. I have a lot of experience
designing scene-graphs. Will be happy to discuss it with u. I have a class
structure that works very well.
-----Original Message-----
From: Jonathan Wight [mailto:JW...@bi...]
Sent: Wednesday, September 06, 2000 11:06 AM
To: gda...@li...
Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs
on 9/6/00 12:37 PM, Stephen J Baker at sj...@li... wrote:
>> So where does Inventor and the *.iv format fit into this now that (I
>> believe) it has become an open-source environment?
>
> There are dozens of OpenSourced scene graph API's out there.
> Inventor becomes yet another. There are dozens of file formats
> out there - .iv becomes yet another (and it's essentially just
> VRML anyway - IIRC)
>
> Adding another to the existing pile doesn't make for standardization.
Would one size fit all? I have my own set of requirements for a scene graph,
didn't find anything out there that suited these requirements - which is why
I'm forced to write my own. I don't think it is possible to create scene
graph library and make it as generically useful as for example the C++ STL.
Which reminds me, are there any design patterns relating to scene graphs
anywhere? Had a quick look but didn't find anything.
Jon.
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
|
|
From: Jonathan W. <jw...@bi...> - 2000-09-06 21:44:09
|
on 9/6/00 1:36 PM, Ko, Manchor at MAN...@ca... wrote:
> Now there isn't. But you should be familiar with Performer and Fahrenheit as
> a start. Otherwise you are in a huge hole. I have a lot of experience
> designing scene-graphs. Will be happy to discuss it with u. I have a class
> structure that works very well.
What is happening with Fahrenheit BTW? Is it dead? I found a news link
yesterday that seemed to say it was alive and doing well but I couldn't
confirm it.
Also has anyone got any good links to some Fahrenheit technical
documentation?
Jon.
|
|
From: Matthew M. <ma...@me...> - 2000-09-06 23:19:21
|
Well, I can tell you that I was accepted into the Fahrenheit eXtensible
Scene Graph beta program about six months ago and never received a single
build...not the best indication of health.
-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Jonathan Wight
Sent: Wednesday, September 06, 2000 2:46 PM
To: gda...@li...
Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs
on 9/6/00 1:36 PM, Ko, Manchor at MAN...@ca... wrote:
> Now there isn't. But you should be familiar with Performer and Fahrenheit
as
> a start. Otherwise you are in a huge hole. I have a lot of experience
> designing scene-graphs. Will be happy to discuss it with u. I have a class
> structure that works very well.
What is happening with Fahrenheit BTW? Is it dead? I found a news link
yesterday that seemed to say it was alive and doing well but I couldn't
confirm it.
Also has anyone got any good links to some Fahrenheit technical
documentation?
Jon.
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
|
|
From: Gavan H. <gh...@si...> - 2000-09-07 11:32:14
|
The product will be turning up shortly as far as I heard, but I am not in
any position to know when. It has had an active beta program. I recvd
regular beta copies, it was one of the few beta programs that sends out hard
copy manuals even.
So as far as committment from the XSG team I cannot fault them, good effort,
even If you are not for MS products don't begrudge the team their efforts
for bringing through a product with little hype and committment to
quality.They supported OpenGL in the product equaly to Direct X.
If you were accepted onto the beta you would have recvd cds, printed manuals
on more than one occasion and access to the private newsgroups. If you did
not get this stuff then something must have went wrong with your details I
would say.
Gavan
-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Matthew MacLaurin
Sent: Thursday, September 07, 2000 9:19 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs
Well, I can tell you that I was accepted into the Fahrenheit eXtensible
Scene Graph beta program about six months ago and never received a single
build...not the best indication of health.
-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Jonathan Wight
Sent: Wednesday, September 06, 2000 2:46 PM
To: gda...@li...
Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs
on 9/6/00 1:36 PM, Ko, Manchor at MAN...@ca... wrote:
> Now there isn't. But you should be familiar with Performer and Fahrenheit
as
> a start. Otherwise you are in a huge hole. I have a lot of experience
> designing scene-graphs. Will be happy to discuss it with u. I have a class
> structure that works very well.
What is happening with Fahrenheit BTW? Is it dead? I found a news link
yesterday that seemed to say it was alive and doing well but I couldn't
confirm it.
Also has anyone got any good links to some Fahrenheit technical
documentation?
Jon.
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
|
|
From: Eugene F. <fo...@dr...> - 2000-09-07 00:14:32
|
Jonathan Wight wrote: > What is happening with Fahrenheit BTW? Is it dead? I found a news link > yesterday that seemed to say it was alive and doing well but I couldn't > confirm it. > > Also has anyone got any good links to some Fahrenheit technical > documentation? SGI pulled out when they finally realized what Fahrenheit was...a poorly-concealed attempt by Microsoft to kill OpenGL. Microsoft had little use for it after SGI made it clear that they weren't going to obsolete OpenGL in favor of it. So they both just let it drop. I was truly worried about SGI when they announced they were working on Fahrenheit in the first place. Companies that "partner" with Microsoft have a funny way of disappearing one way or another. When SGI pulled out of Fahrenheit my heart sang. Eugene |
|
From: Stefan B. <ste...@te...> - 2000-09-07 09:26:19
|
> What is happening with Fahrenheit BTW? Is it dead? I found a news link > yesterday that seemed to say it was alive and doing well but I couldn't > confirm it. XSG (Nee FSG) 1.0 has been released by Microsoft, but it is not available for free. > Also has anyone got any good links to some Fahrenheit technical > documentation? Since the SDK is not free, there is no freely available documentation, I'm afraid! Cheers, Stef -- Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd. bo...@te... |
|
From: Paul B. <pbl...@di...> - 2000-09-06 20:21:03
|
I think that is more of a abstract data type isn't it? Most scene graphs utilize a number of design patterns and would probably be best described as "composite" or "compound" patterns (not to be confused with the Composite [GOF] pattern). For example, Composite, Observer, Strategy, Dual Dispatch, Abstract Factory, Prototype, Builder, and Visitor have all been used in scene graph work. Paul > -----Original Message----- > From: Graham S. Rhodes [mailto:gr...@se...] > Sent: Wednesday, September 06, 2000 1:54 PM > To: gda...@li... > Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs > > > Jon wrote, > > > Which reminds me, are there any design patterns relating to > scene graphs > > anywhere? Had a quick look but didn't find anything. > > "Directed Acyclic Graph"? Could that be considered a pattern? > > Graham > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Ko, M. <MAN...@ca...> - 2000-09-06 21:17:58
|
With instance sharing a scene graph is not a DAG. -----Original Message----- From: Graham S. Rhodes [mailto:gr...@se...] Sent: Wednesday, September 06, 2000 11:54 AM To: gda...@li... Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs Jon wrote, > Which reminds me, are there any design patterns relating to scene graphs > anywhere? Had a quick look but didn't find anything. "Directed Acyclic Graph"? Could that be considered a pattern? Graham _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
|
From: Stefan B. <ste...@te...> - 2000-09-06 22:20:40
|
> With instance sharing a scene graph is not a DAG. How is it not? Instance sharing merely means that there can be more than one arc to a node, but it does not introduce any cycles in the graph. Cheers, Stef -- Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd. bo...@te... |
|
From: Ko, M. <MAN...@ca...> - 2000-09-06 23:13:26
|
I had the Beta docs. - not sure whether I am suppose to make it generally
available or not.
-----Original Message-----
From: Jonathan Wight [mailto:jw...@bi...]
Sent: Wednesday, September 06, 2000 2:46 PM
To: gda...@li...
Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs
on 9/6/00 1:36 PM, Ko, Manchor at MAN...@ca... wrote:
> Now there isn't. But you should be familiar with Performer and Fahrenheit
as
> a start. Otherwise you are in a huge hole. I have a lot of experience
> designing scene-graphs. Will be happy to discuss it with u. I have a class
> structure that works very well.
What is happening with Fahrenheit BTW? Is it dead? I found a news link
yesterday that seemed to say it was alive and doing well but I couldn't
confirm it.
Also has anyone got any good links to some Fahrenheit technical
documentation?
Jon.
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
|
|
From: Stefan B. <ste...@te...> - 2000-09-07 09:26:18
|
> I had the Beta docs. - not sure whether I am suppose to make it generally > available or not. Most definitely not! They're not public docs and your NDA does not allow you to share that material. Cheers, Stef -- Stefan Boberg, R&D/Technical Manager, Team17 Software Ltd. bo...@te... |
|
From: Scott M. <sc...@3d...> - 2000-09-06 19:09:41
|
> -----Original Message----- > From: Jonathan Wight [mailto:JW...@bi...] > Sent: Wednesday, September 06, 2000 1:06 PM > To: gda...@li... > Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs > > > on 9/6/00 12:37 PM, Stephen J Baker at sj...@li... wrote: > > >> So where does Inventor and the *.iv format fit into this > now that (I > >> believe) it has become an open-source environment? > > > > There are dozens of OpenSourced scene graph API's out there. > > Inventor becomes yet another. There are dozens of file formats > > out there - .iv becomes yet another (and it's essentially just > > VRML anyway - IIRC) > > > > Adding another to the existing pile doesn't make for > standardization. > > Would one size fit all? _Maybe_, but it is a tough problem to solve. Put too much functionality in a scene graph and it starts to look bloated because most apps will only use a (small?) subset of that functionality. OTOH, if you make it too simple and people end up having to write a bunch of code to use it then they will perceive it to be not very useful. This, combined with having to work within an externally imposed structure, could lead a person to consider "just doing it himself". > I have my own set of requirements for > a scene graph, > didn't find anything out there that suited these requirements > - which is why > I'm forced to write my own. I don't think it is possible to > create scene > graph library and make it as generically useful as for > example the C++ STL. > Agreed, because a scene graph is a much higher-level construct than the things in STL. > Which reminds me, are there any design patterns relating to > scene graphs > anywhere? Had a quick look but didn't find anything. > Composite is what a scene graph is IIRC. The Visitor pattern is also used for traversing the graph in some implementations. Scott McCaskill sc...@3d... |
|
From: Neal T. <ne...@ps...> - 2000-09-07 17:25:36
|
RE: [Algorithms] FW: [CsMain] Scene Graphs From: Scott McCaskill=20 _Maybe_, but it is a tough problem to solve. Put too much = functionality in a scene graph and it starts to look bloated because = most apps will only use a (small?) subset of that functionality. OTOH, = if you make it too simple and people end up having to write a bunch of = code to use it then they will perceive it to be not very useful. This, = combined with having to work within an externally imposed structure, = could lead a person to consider "just doing it himself". I believe that the "Renderware" approach of having many small = components arranged in hierarchical layers, with the ability to plug in = different components at any level, is probably the best general approach = for truly reusable "scene graph" code. The core or base level can then = contain no actual scene graph code at all, just helper components such = as a platform independent interface for rendering blocks of data, matrix = support, chunk streaming functions, texture and image handling, and so = on. The next layer up might be a very basic scene graph / 3d engine, = and additional functionality such as skinning or animations can be added = as higher level plugins. Having said that, we are no longer actually using RenderWare as = opposed to our own code written along similar lines, so perhaps even = this approach may not be quite good enough for everyone:-) Neal Tringham (Sick Puppies) ne...@ps... ne...@em... |
|
From: Aaron D. <ri...@ho...> - 2000-09-07 03:38:40
|
I've been also looking for info on this. The best one I've found so far is Numerical Design's whitepaper on their game engine. http://www.ndl.com/wpapers/bishop.html It provides a good general overview of design philosophies and their implementations for collision detection, culling, traversal, etc. without delving into their API specifics. I've also seen several good pages on Java3D that talk about its design's pro's/con's but I don't have the references. A search should turn up something. Graham's posted a few links earlier which I found were very useful. (Thanks Graham!) - Aaron -----Original Message----- From: Dave Smith <Dav...@sd...> To: gda...@li... <gda...@li...> Date: Thursday, 7 September 2000 13:06 Subject: Re: [Algorithms] FW: [CsMain] Scene Graphs > >Jonathan Wight wrote: >> Which reminds me, are there any design patterns relating to scene graphs >> anywhere? Had a quick look but didn't find anything. >> >> Jon. >> > >Good question. I have just been browsing the popular >API's (Performer, Java3D, PHIGS, etc..) for ideas but that's >a major pain. > >-DaveS >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X