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".
