Hear hear. Great post, I have been working on a Java3D game for the last year, without any prior 3D experience, but a good background in java. The level of frustration is sometimes unbearable but I do usually work through my problems after extensive hours of reading and testing. You are correct about one thing, nothing is more frustrating than knowing somebody else has figured out an issue you ask about and doesn't answer your question after you've been beating your head gaainst a wall for a month on it.
Keep up the good work, I've been following the cosm project and it is very similiar to the type of game world I've been working on and I am thoroughly impressed with what you guys have accomplished. Create an archive on how you do all the types of things you have implemented someday and that would be a tremendous contribution to the java3D community, the lack of real world examples for complex 3D issues severely limits so many of us solo developers who don't have 24 hours a day to reinvent the wheel but are willing to learn and understand what makes java3D tick. > Justin posted a response to my e-mail that struck a fairly emotional > chord in me. He pointed out that the techniques I am going to attempt > for doing large scale forests and vegetation could be considered "tried > and trusted techniques". (and BTW way thanks for the link Justin, I > will check it out). > > I do know some of these techniques have been used before to great > effect, although I have not read about combining multiple images into > composite textures. I have also not read about anyone implementing > weeds and ground cover using what amounts to an adapted particle > system. In general I have found many techniques discussed in white > papers or on flipcode or gamedev or opengl.org to not very usable > within the context of a scenegraph > architecture. Trying to apply articles on radiosity, lightmapping, > BSP, shadow volumes, skin and bones, collision detection and bump > mapping to the Java3d framework can quickly lead to premature grey > heads. I spend about 20 percent of my Cosm development time reading and > adapting techniques found in various places. It is my hopes that we > don't reinvent the wheel any more than we need to. > > I, nor anyone on the Cosm team, have any prior 3d programming > experience. This has resulted in a lot of hard lessons, dead ends and > wasted time. I know there are a lot of people out there that take > their knowledge for granted and forget that we all had to start > somewhere. I think that simultaneously learning 3d concepts and the > java3d API was perhaps a mistake :) Personally I have found that there > is a large gap between techniques and practical applications. > > The other thing I have found is that sometimes you discovery new ways > of doing things by *not* taking someone else algorthms or using > "standard methods". I remember when we worked on the sky stuff I read > everything at vterrain.org and every single paper I could find on > rendering skies. Our final solution has some unique elements which may > not have been there had we implemented something from a book. > > I am hoping before all of us collectively are finished with our various > projects we will have assembled enough information and examples to save > the next generation java3d programmers from similar experiences. > > And now on to the rant... > > There is something I have learned a lot over the last 20 months of > working on Cosm. The knowledge on *how* to build a full implementation > of a first/third person 3d game is rare to non-existant. I think there > are probably a handful of people in the world that know how to do all > of the following things: > > 1. Net lag tolerant code > 2. Client side prediction on for N objects moving with orientation, > mass and velocity. > 3. Collision detection > 4. 3d skeletal deformation and texturing > 5. Texture and geometry caching, paging, loading and lots of other > resource management > 6. Advanced 3d: lighting, shadowing, occlusion culling, portals, > line-of-sight > 7. particle systems > 8. sky-domes, clouds, sun/moon/stars, rain, snow > 9. asset management for project (textures, animations, models, sounds) > 10. 3d gui development > 11. terrain/landscapes > 12. level of detail management > 13. water > 14. building effective tools for world management, importing/converting > models, etc. > > Well the list goes on and on. > > We started out with zero knowledge and have slowely implemented most of > the above and more without any code except our own. The knowledge on > *how* to do it was a combination of reading books, the internet and > electronic lists. one of the reasons we spend so much time helping > other groups and other developers via e-mail, icq and the e-lists is > beause we know the frustration of trying to figure out stuff you just > *know* someone has already figured out. > > Take any topic... say how do you create clouds and animate them > realistically.. well you do this: > > 1. you search the archives of all the gamedev boards (flipcode, > gamedev, etc). You will find some *hints* but nothing which really > explains it. 2. Search google. and you will find several good white > papers. very obtuse. You will go to vterrain.org and get a little more > help. > 3. You will try some things out and write some very slow code which > does not work in real time. > 4. ask some questions on the e-lists and get very broad advice like > "build a skybox and scroll your clouds by animating the texture > coordinates". You will try this and determine that the two techniques > can be mutually exlusive, since the sky boxes need a perspective > correction. so then you read about sky domes and you get that to work. > So then you say, well I want to fade at the horizon and you want to > layer for effect. Days later you finnally figure out how to blend with > nesting sky domes... but then it is too slow... so days later you > figure out how to use a special blending mode and use a polygon offset > to adjust z-buffer values for fast belnding... then you realize the sky > needs to stay in the background while you move... so you start out by > transforming the sky meshes on every frame to keep you centered, until > you realize that is wasting even more time... so you realize you can > draw the whole thing as within a unit perspective and disable z-buffer > writes... and it goes on and on and on. > > sorry for the long winded example. but the point is that the knowledge > is hard fought and....guarded by people that either dont have the time > to lay it out for you, or who are jelously gaurding the information. > Even many people who know all the things I listed above only *think > they know*, for I would maintain that until you have to actually build > it and make a product does the knowledge cease being theoretical and > start being practical. > > > Even Sun, who should be helping use thier own tools, don't *really* > help, but instead offer broad advice most of the time. They might > answer a very specific question, but don't really give you enough > information to solve the *real* problem. One sun engineer once said to > me "I implemented a quake syle occlusion culling and visiblily > detection using a combination of switchnodes and alternate appearances" > but thats just enough information to run with... for a month. There > are a lot of questions posted to this group that would benefit from a 2 > paragraph answer from Sun. I know that is not their job. Their job is > the creation and support of Java3d. But I for one just know that they > know how to do all the things we are all trying to figure out. I have > followed the work of Kelvin in particular and consider him one of the > the most knowlegable people on the planet when it comes to 3d > programming. It is too bad that Sun only has time to comment on the > technical use of their API and does not have time to lead us in the > proper direction for actually using the API to solve our very real > problems. > > I have gotten to know the various Java3d experts over time, and some > now consider me to be such an expert... but there is almost ZERO code > sharing. Only one person has ever sent me a truely useful piece of > java3d technology (Thanks John White). And another person said.. well > it will cost you to use our animation code... and when I ask the cost > and offered several 100 bucks, he said that was too little and we > dropped the conversation. > > We could have bought the net-immerse engine for some 20-70k, and no > doubt our time spent implementing the exact same thing will far, far > exceed that cost in the long run.. (Actually we are closer to $600K at > this point in sheer programming hours) but fact is most groups wanting > to build a game can't afford that. This means only a very few dedicated > and talanted groups can ever build a fully working 3d game all the way > to production status, and a few rich companies can do it. > > Because it is sooo hard, and requires so much time and talant people > who *have* done it either want a lot of money, or they lack the time to > get their code generic enough that it can be used by others.... so > everyone keeps doing it on their own, occasioanlly dropping a few vague > (but often helpful hints) to the people beginniing their journey of > exploration. > > There is also a certain attitude... the attitude is "well I spent years > figuring this out, why shouldn't you figure this out too?" This > attitude is *very* prevalent and I run into it (unspoken) all the time. > The other issue is that much of the knowledge cannot be just handed to > someone. If you hand them something so easy to use that it only > requires a > plug-it-in-any-monky-can-use-it knowledge, than as soon as they step > outside the implementation box they have no idea how to improve it, > because to improve it would require a deep understanding of the > workings of all the sub-systems and underlying theory... and if you > already have that then why not write it yourself exactly to the spec > yout need? > > So the problem of re-inventing the wheel continues to re-inforce > itself. > > Maybe Sun will release a library someday that has all these things > needed to build a game from a "glue" perspective. (And I know there is > a project to do just that) Maybe this will facilitate game making and > you will see a bunch of games spring up... I am sure this will be good > for people who want to build games, and see the tools as a means to the > end. But without the underlying knowledge there will be a limit to how > innovative their games can be, and frankly they *will* be benefitting > from the hard earned knowledge of the few people who sacrificed to do > it. > > The java3d list as a whole does not suffer this disease to the same > degree as other places. Most people here are sincerely interested in > sharing knowledge (Justin Couch, Daniel Selman and Fred Klingener being > prime examples). But there are also a lot of people on this list that > are clearly 3D experts with deep knowledge of 3D concepts both > practical and > theoretical. I can tell by the types of questions they ask. When > someone shows up on the list and their first question is an issue with > dot combiners and multi-texturing then you know they are no novice. I > hope that as we help solve their API issues they can in turn help > educate us on the the concepts behind the API, and help us evolve our > understanding on the practical usage of the various techniques. > > /rant off > > Dave > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body of the message "signoff JAVA3D-INTEREST". For general help, send > email to [EMAIL PROTECTED] and include in the body of the message > "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
