Wolfram Kuss writes:
> >The bigger problem, I suspect, will be main memory (or maybe disk
> >bandwidth). An impostor scheme is going to be really tile hungry --
> >constantly dragging tiles off of disk, rendering them into textures,
> >and forgetting about them.
>
> I know a sim that do
>The bigger problem, I suspect, will be main memory (or maybe disk
>bandwidth). An impostor scheme is going to be really tile hungry --
>constantly dragging tiles off of disk, rendering them into textures,
>and forgetting about them.
I know a sim that does what Norman suggest and it does not s
Curtis L. Olson wrote:
> One thing we'd need to think about before we got too far down this
> path is the texture RAM requirements of such a scheme.
That's a manageable problem. If you think about it, the amount of
impostor texture memory required is exactly that required to draw the
tiles on
David Megginson writes:
> Curtis L. Olson writes:
>
> > One thing we'd need to think about before we got too far down this
> > path is the texture RAM requirements of such a scheme.
>
> They should be minimal. For the first tier of imposter tiles, we're
> using textures that we already have,
Curtis L. Olson writes:
> One thing we'd need to think about before we got too far down this
> path is the texture RAM requirements of such a scheme.
They should be minimal. For the first tier of imposter tiles, we're
using textures that we already have, and just replacing the tile with
a sin
David Megginson writes:
> Norman Vine writes:
>
> > but IMHO what is needed are "imposter tiles"
> >
> > "imposters" are where you use a 'texture only" substitute
> > for the geometry that are computed on the fly 'often enough'
> > This is 'radical' LOD but in our case the tiles out on the
> Yes, I think that's a very good idea; in fact, if you wanted to go to
> three layers, the furthest one could be simply untextured, coloured
> polys (that's what you'd see from 120,000ft, for example). For each
> tile, we need to sample to find the commonest material and then use it
> for the te
David Megginson wrote:
> Norman Vine writes:
>
> > but IMHO what is needed are "imposter tiles"
> >
> > "imposters" are where you use a 'texture only" substitute
> > for the geometry that are computed on the fly 'often enough'
> > This is 'radical' LOD but in our case the tiles out on the
Norman Vine writes:
> but IMHO what is needed are "imposter tiles"
>
> "imposters" are where you use a 'texture only" substitute
> for the geometry that are computed on the fly 'often enough'
> This is 'radical' LOD but in our case the tiles out on the
> boundary are really just 'little s
> Erik Hofman writes:
> >
> >I'm realy impressed by the effect of the code. The higher I get, the
> >higher the framerate! This makes me believe we could actually enlarge
> >the view range when getting at a higher altitude.
This would be really nice for very high flying ("X") aircraft.
Jon
_
Erik Hofman writes:
>
>I'm realy impressed by the effect of the code. The higher I get, the
>higher the framerate! This makes me believe we could actually enlarge
>the view range when getting at a higher altitude.
Cool glad it works for you
but IMHO what is needed are "imposter tiles"
"impost
Norman Vine wrote:
> Erik Hofman writes:
>
>>Norman Vine wrote:
>>
>>
>>>I'd better just go back into lurk mode I guess
>>>
>>Preferably not. The code improves the framerate by a factor which you
>>meantioned earlier, but also makes the framerate quite steady.
>>
>>So you must have done something
Norman,
This does appear to work great! Thanks for tracking this down. I
able to fly successfully both at KBOS and KSFO which I couldn't do
before.
Thanks,
Curt.
Norman Vine writes:
> Curtis L. Olson writes:
> >>
> >Again to summarize, we value your participation, and normally you
> >produ
Curtis L. Olson writes:
>>
>Again to summarize, we value your participation, and normally you
>produce very robust code, but in this case since we never know when
>you are lurking or not, it's difficult to accept broken code with no
>promise of a fix ...
Hey thanks for the lecture and I'll leave
> Really, we need a routine that works with an arbitrary ssg scene
> graph. It's very concievable that someone could import scenery from
> some other project with a completely different layout. Also, we are
> talking about non-vertical intesection lines when it comes to landing
> gear, so a line
Norman Vine writes:
> Curtis L. Olson writes:
> >
> >> I'll try testing with KBOS again but I was teleporting there
> >> as part of my regression testing because of its unique tile
> >> arrangement
> >
> >Try --airport-id=KBOS --heading=270
> >
> >> Yikes good catch :-(
> >>
> >> Hmm. hey thi
David Megginson wrote:
> Curtis L. Olson writes:
> > I had to copy sgdPointInTriangle() as well as one other routine from
> > the old hitlist.cxx to get things to compile. We made a decision a
> > while back that we wouldn't require a development version of plib,
> > but require only the mos
Curtis L. Olson writes:
>
>> I'll try testing with KBOS again but I was teleporting there
>> as part of my regression testing because of its unique tile
>> arrangement
>
>Try --airport-id=KBOS --heading=270
>
>> Yikes good catch :-(
>>
>> Hmm. hey this still works in my test bed :-)
>
>What I
Norman Vine writes:
> the routine has the 'smarts' to try the whole graph if and
> when it doesn't get an intersection in the 'current tile' so
> the tile boundary thing shouldn't be the problem.
Ok, that sounds correct.
> I'll try testing with KBOS again but I was teleporting there
> as part
Curtis L. Olson writes:
> I had to copy sgdPointInTriangle() as well as one other routine from
> the old hitlist.cxx to get things to compile. We made a decision a
> while back that we wouldn't require a development version of plib,
> but require only the most recent 'stable' version. So, t
Norman Vine wrote:
> My apologies for the line noise
>
> I'd better just go back into lurk mode I guess
Preferably not. The code improves the framerate by a factor which you
meantioned earlier, but also makes the framerate quite steady.
So you must have done something right!
:-)
Erik
_
Curtis L. Olson writes:
>
>Norman Vine writes:
>> tarball for new hitlist code
>> http://www.vso.cape.com/~nhv/files/fgfs/new_hitlist.tgz
>>
>> For those of you not using the CVS version of PLib
>> you will need a copy of sgdPointInTriangle()
>> from the older hitlist.cxx this one replaces
>
>
>
Norman Vine writes:
> tarball for new hitlist code
> http://www.vso.cape.com/~nhv/files/fgfs/new_hitlist.tgz
>
> For those of you not using the CVS version of PLib
> you will need a copy of sgdPointInTriangle()
> from the older hitlist.cxx this one replaces
Norman,
Thanks for your continued wo
23 matches
Mail list logo
