Artur Biesiadowski wrote: > After quick browsing your terrain code, it seems to me that you allow > either colors or texture, not both (so no modulating by texture etc).
I did that last night as a memory usage thing. I'm trying to find out why I'm running out of memory on a 1K square grid. Is it j3d, my stuff, or something else? Paul's original code had no support for colours. I added that in late yesterday afternoon so it wasn't a direct design decision, just exploring adding more features ATM. I also am adding paged/tiled textures support. The APIs are there, but they aren't being used currently. That should happen over the next day or so. Out of interest, why would you want to blend the texture and colour information? In addition, would you want multi-texturing in there? > Also there seems to be no generation/support for normals. Are my > assumptions correct ? If yes, then is this design decision or you just > wanted to have basics quick and are happy if anybody else will implement > these missing parts ? Another case of "it wasn't in Paul's code so I haven't gotten around to it yet". I'm sure I can quickly add the API calls for that and then let someone else do the implementation work. It would have to be done quickly, because I'm moving pretty fast on that code currently. More optimisations yet to be done (put the FastQueue stuff back in, sub-tree re-optimisation etc). Another area that I want to get fixed is the calculation of interpolated height from the grid cell so that I can start integrating the faster calc routines for the nav code. So, what's on the TODO list? This is what I can think of off the top of my head: - Appearance handling. I'd like to allow the end-user to control the appearance rather than having it generated internally. Allows the end user to do stuff like changing to line mode or controlling lighting calcs. Have to be careful though because we want to start doing texture paging as well, which may mean separate textures for each patch and hence separate appearance instances. - Nav code to use the new interfaces for fast terrain following - Texture tiling/paging to allow support for large terrains - Optimisations of patch management - Adding and removing patches from the scenegraph as the user moves around so that we can keep total memory consumption under control - An implementation of some form of dynamic loading/unloading of the height-grid information (eg allow navigation over multiple DEMs and swap in/out as necessary - Further optimisation of ROAM algorithms. Paul pointed me at this message, which is what I'm going to be following in future work: http://www.cognigraph.com/ROAM_homepage/phases.html - Addition of vertical structure information into the patch structure. Buildings etc should also be subject to the LOD handling too. Paul mentioned something about having implemented a technique for doing this for his City of Bath project. Going to be talking to him on the phone a bit later today for various things so will also chat about this. -- Justin Couch http://www.vlc.com.au/~justin/ Freelance Java Consultant http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- =========================================================================== 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".
