Jon
30-04-2007 19:07:51
I've been away from Ogre stuff for a bit, but have managed to free up some time just as Einhort is released. I have a few pet projects (one was a severe LOD issue -- turning off LOD isn't a viable option), the other is a terrain generator I've been working on.
With respect to the LOD issue, I read about a problem with ray queries which may explain what I was seeing. When I took code from my own rendering engine (a grad school project from a while back) and placed it in PLSM for comparison, I was unable to come up with anything consistent. Looking back, I realize both LOD systems were using the same ray query values. So I'll put this on the back burner for a week or so, when I'll have time to dig into it more.
As for the terrain generator, I recall a rather long complicated process between the time my generator finished and when I was able to view the terrain in Ogre. I can't help but think it would be nicer if my generator could skip the map splitter and produce a PLSM compatible dataset directly.
Now that I've explained the motivation, I'll get to the concrete questions shortly.
I started by observing the files which the map splitter produced (a lot of the map splitter functionality isn't required for what I'm doing):
* split heightmap
* split coverage map
* split alpha map
* split base map
* split horizon maps
In an ideal world, we'd have a nice document which described these file formats as part of an interface description. But since we don't yet have this document, I'm going to need to gather the info together.
Looking at how the data is used when it is read in is a good way of building a description. When I look at the horizon data I was able to follow it up until the point where it is loaded into the GPU (if I am understanding things). I expected to see a GPU program, or something which referred to "HorizonSettings", however a search of the entire Ogre/PLSM tree turned up only the code in OgrePagingLandScapeTexture.cpp [PagingLandScapeTexture::lightUpdate()]
Can anyone shed light on where this data is used?
Also, it appears that the sun is treated as if it was on a single plane moving E-W through the zenith. Does that sound correct?
With respect to the LOD issue, I read about a problem with ray queries which may explain what I was seeing. When I took code from my own rendering engine (a grad school project from a while back) and placed it in PLSM for comparison, I was unable to come up with anything consistent. Looking back, I realize both LOD systems were using the same ray query values. So I'll put this on the back burner for a week or so, when I'll have time to dig into it more.
As for the terrain generator, I recall a rather long complicated process between the time my generator finished and when I was able to view the terrain in Ogre. I can't help but think it would be nicer if my generator could skip the map splitter and produce a PLSM compatible dataset directly.
Now that I've explained the motivation, I'll get to the concrete questions shortly.
I started by observing the files which the map splitter produced (a lot of the map splitter functionality isn't required for what I'm doing):
* split heightmap
* split coverage map
* split alpha map
* split base map
* split horizon maps
In an ideal world, we'd have a nice document which described these file formats as part of an interface description. But since we don't yet have this document, I'm going to need to gather the info together.
Looking at how the data is used when it is read in is a good way of building a description. When I look at the horizon data I was able to follow it up until the point where it is loaded into the GPU (if I am understanding things). I expected to see a GPU program, or something which referred to "HorizonSettings", however a search of the entire Ogre/PLSM tree turned up only the code in OgrePagingLandScapeTexture.cpp [PagingLandScapeTexture::lightUpdate()]
GpuProgramParametersSharedPtr params = mMaterial->getBestTechnique()->getPass(0)->getFragmentProgramParameters();
#ifdef PLSM2_EIHORT
params->setNamedConstant("HorizonSettings", Vector4(SunDir.x, SunDir.y, SunDir.z, LightAngle));
#else
Can anyone shed light on where this data is used?
Also, it appears that the sun is treated as if it was on a single plane moving E-W through the zenith. Does that sound correct?