--- Log opened Thu Jan 19 00:00:59 2006
01:34 >> #worldwind-dev JOIN [1]adamhill (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
01:36 >> SignOff: T_Servo (Read error: 113 (No route to host)) [#worldwind-dev]
01:38 >> #worldwind-dev JOIN T_Servo (n=chatzill@205.208.132.235)
01:48 >> SignOff: adamhill (Read error: 110 (Connection timed out)) [#worldwind-dev]
01:48 >> [1]adamhill is now known as adamhill
01:57 >> Bull_[UK] is now known as Bull_[Zzz]
02:11 >> #worldwind-dev JOIN [1]adam_GFX2 (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
02:15 >> SignOff: adamhill (Read error: 110 (Connection timed out)) [#worldwind-dev]
02:22 >> SignOff: adam_GFX2 (Read error: 110 (Connection timed out)) [#worldwind-dev]
02:22 >> [1]adam_GFX2 is now known as adam_GFX2
02:34 >> #worldwind-dev JOIN [1]adam_GFX2 (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
02:36 >> #worldwind-dev JOIN adamhill (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
02:37 >> #worldwind-dev JOIN [2]adam_GFX2 (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
02:38 >> SignOff: T_Servo ("Chatzilla 0.9.68a [Firefox 1.0.6/20050716]") [#worldwind-dev]
02:50 >> #worldwind-dev JOIN [3]adam_GFX2 (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
02:52 >> SignOff: adam_GFX2 (Read error: 110 (Connection timed out)) [#worldwind-dev]
02:52 >> SignOff: [1]adam_GFX2 (Read error: 110 (Connection timed out)) [#worldwind-dev]
02:53 >> #worldwind-dev JOIN adam_GFX2 (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
02:53 >> #worldwind-dev JOIN [2]adamhill (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
03:06 >> SignOff: [2]adam_GFX2 (Read error: 110 (Connection timed out)) [#worldwind-dev]
03:06 >> SignOff: adamhill (Read error: 110 (Connection timed out)) [#worldwind-dev]
03:06 >> [2]adamhill is now known as adamhill
03:10 >> SignOff: [3]adam_GFX2 (Read error: 110 (Connection timed out)) [#worldwind-dev]
03:24 >> #worldwind-dev JOIN [1]adamhill (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
03:24 >> #worldwind-dev JOIN [1]adam_GFX2 (n=adamhill@adsl-70-136-51-172.dsl.hstntx.sbcglobal.net)
03:38 >> SignOff: adamhill (Read error: 110 (Connection timed out)) [#worldwind-dev]
03:38 >> [1]adamhill is now known as adamhill
03:39 >> SignOff: adam_GFX2 (Read error: 110 (Connection timed out)) [#worldwind-dev]
03:39 >> [1]adam_GFX2 is now known as adam_GFX2
06:00 >> Urobots is now known as URobots
06:29 >> #worldwind-dev JOIN mazop (n=mazop@212.183.13.231)
07:16 >> SignOff: barnacle9 (Read error: 104 (Connection reset by peer)) [#worldwind-dev]
09:36 >> SignOff: URobots (Read error: 110 (Connection timed out)) [#worldwind-dev]
09:39 >> SignOff: dpatton_away (Excess Flood) [#worldwind-dev]
09:40 >> #worldwind-dev JOIN dpatton_away (n=dpatton@S01060011950c1533.vc.shawcable.net)
11:17 >> mazop is now known as mazop_away
12:07 >> mazop_away is now known as mazop
14:37 >> #worldwind-dev JOIN adamhill_work (n=86a3fd7e@70.84.174.194)
15:30 >> dpatton_away is now known as dpatton
15:46 >> #worldwind-dev JOIN URobots (n=irc@c-71-193-152-168.hsd1.or.comcast.net)
17:06 >> #worldwind-dev PART mazop (n=mazop@212.183.13.231) ()
17:31 >> Bull_[Zzz] is now known as Bull_[UK]
18:41 < URobots> so mashi
18:41 < URobots> of the strut removal options
18:42 < URobots> #1 -- vertex shading
18:42 < URobots> (ala hoppe)
18:42 < URobots> #2 -- prevent zbuffer clearing
18:42 < URobots> (assuming it works)
18:43 >> SignOff: f0urtyfive () [#worldwind-dev]
18:45 < URobots> #3 -- image accessor to control single access to texturing the terrain
18:45 < URobots> (feels like overkill)
18:46 < mashi> explain #3?
18:46 < URobots> #4 -- shorten the struts, perhaps dynamically based on the camera height and obliquity
18:47 < URobots> #5 -- just leave with the gaps, but only when needed :-)
18:47 < URobots> these are what have popped in my head, curious to see if you have any others
18:47 < URobots> re: #3 --
18:49 < URobots> the approach I'm thinking is to effectively handle zbuffering for terrain textures on our own (seems overkill but we have relatively few terrain layers), and...
18:50 < URobots> do this but making a strong imageaccessor, similar to the way the terrain accessor gates access to a primary mesh
18:50 < URobots> Then, when a QTS (or imagelayer) wants to draw to a mesh, it draws to only the imageaccessor (a bit of a misnomer)
18:51 < URobots> which will then effectively cause only a single seamless layer to be drawn
18:52 < URobots> in this case, we end up with no need to worry about the struts -- we can leave with them, assuming
18:52 < URobots> we are always rendering something on the terrain to hide them
18:52 < URobots> I haven't played enough with ImageAccessor to figure out if this is a minor fix or not(I realize that
18:52 < dpatton> doesn't that approach fall apart when you want to view the scene in Wireframe?
18:53 < dpatton> to do things like the wireframe views on this page: http://members.shaw.ca/davepatton/demcompare.html
18:53 < URobots> (I realize that in the code, the approach would be polled in the opposite direction, with the image accessor asking the layers to render - it was just easier to explain the other way)
18:54 < URobots> dp -- yup -- it wouldn't get rid of the struts, it would just make them inconsequential - much like they are now for normal planet viewing
18:55 < URobots> dp -- I've always thought of the wireframes as just debug
18:55 < URobots> dp -- and if you were to do dem comparison and the like (I like the link, btw) then you would
18:56 >> SignOff: adamhill_work ("CGI:IRC (Ping timeout)") [#worldwind-dev]
18:56 < URobots>  just do a simple monochrome shading off the mesh (or heck, with true sun lighting! -- another thing on my todo list!)
18:56 < dpatton> mashi and I had general discussions 'quite a while ago' that what we'd like to see would be a way to do what you are suggesting(I think) - combine all the layers into one layer, then drape it over the terrain
18:56 < URobots> I know I'm listing it as an option, but I actually don't like it.
18:56 < URobots> for a couple reasons -- first, we're making the CPU do what the GPU should be doing
18:59 < URobots> second, for me (at least), I need to render many multiple layers of terrain. Gating them through on the CPU without access to GPU features will really load on the system
18:59 < URobots> thirdly, I love the statelessness of layers in the current architecture (zbuffering aside)
19:01 < URobots> so I've been doing all the talking it seems. do you guys have other ideas?
19:02 < dpatton> I told you, nobody is here ;-)
19:02 < URobots> My current approach for short term needs, is in order #2, #5, and #4 -- which is simply a reflection of my urgency
19:02 < URobots> yup, you're right
19:02 < URobots> Should I copy an paste into punt-dev? 
19:02 < Bull_[UK]> noe #punt
19:02 < URobots> I was really hoping to catch adam, bull, or ddh into the conversation
19:03 < Bull_[UK]> I'll point ddh to the logs
19:04 < Bull_[UK]> #punt is more used than #punt-dev, imo
19:04 < dpatton> that's true
19:05 < URobots> and don't get me wrong - the gaps are a classic problem in terrain rendering, and the strut solution is quite novel in its simplicity
19:05 < URobots> I like it, but just not for what I need to do (and increasingly, it appears for others as well)
19:08 < dpatton> but, unless I'm wrong, part of the problem is that Chris has a bug in his code, which mashi found, but which isn't yet fixed in Punt's CVS, or WW
19:08 < dpatton> I'm not clear whether or not that bug "really matters" in regards to the current discusion
19:11 < URobots> hmm - what was the bug? From what I've seen, Punt has the same issue with the struts, correct?
19:12 < URobots> (I'm basing that on some screen shots from (I believe) mazop)
19:12 < dpatton> what I'm saying is that mashi's fix for the bug isn't in Punt's CVS, so yes, currently Punt has the same bug as WW
19:13 < dpatton> only mashi knows whether his fix makes the struts go away - from earlier, in #punt, mashi said "my fix isn't in CVS.. I removed the struts"
19:13 < URobots> ah, thanks. Do you know what mashi has done in his local version?
19:13 < URobots> mashi?
19:14 < URobots> ah -- I see - I don't believe he fixed it from his earlier comments
19:14 < URobots> he just removed the struts from rendering
19:15 < dpatton> it was something like: there are 150 samples in a terrain tile, and Chris was using 150 as an upper bound, rather than 149(i.e. 0-149)
19:15 < URobots> which reveals the terrain gapping problem that the struts were put in to fix to begin with
19:15 >> #worldwind-dev JOIN adamhill_work (n=86a3fd7e@70.84.174.194)
19:15 < Bull_[UK]> adam - http://www.worldwindcentral.com/chat/irclog/worldwind-dev/2006-01-19.log
19:16 < URobots> dp -- ah -- that problem is another one I believe. (and one that I too had issues with :-)
19:20 < URobots> dpatton -- do you have any other alternatives on strut removal?
19:21 < URobots> Bull_[UK]?
19:22 < dpatton> it hasn't been an issue for me - I just noticed it recently, both myself with some testing of transparent layers, and from a couple of mazop's screenshots - and as mashi is working on some "terrrain fixes" for Punt, I haven't bothered looking into the issue
19:22 >> #worldwind-dev JOIN mazop (n=mazop@dsl-234-27.utaonline.at)
19:25 < URobots> okeydoke -- sounds like most people are mildly interested, but no one else is hunkering down to fix it (at least at the moment)
19:26 < URobots> for the record, I'd love to hear other potential solutions before I start having to tweak the codebase
19:27 < URobots> and mashi - if you are there, I'd love to hear if you've come up with a fix
19:27 < URobots> :-)
19:28 < Bull_[UK]> hehe I'm not a grphics guy, I'd like a fix, but have no idea how to do it
19:30 < URobots> and just to make sure we're all on the same page -- here is a representation of the artifact:
19:30 < URobots> http://www.urbanrobots.com/Temp/struts.jpg
19:31 < mazop> oh man, i have many of same looking screenshots ;)
19:34 < URobots> oh -- and mazop brought up another option -- only look obliquely south-north :-)
19:34 < URobots> actually... hmmm..
19:34 < mazop> and: "....but no one else is hunkering down to fix it" ...but sorry, i am not a coder....
19:34 < mazop> hehe
19:34 < URobots> is it possible to have both front AND back face culling?
19:35 < URobots> and then render the struts with full culling? or just with wireframe?
19:35 < URobots> do the struts solve the terrain gappings by just having a line, or the entire surface peek through the gap?
19:36 < URobots> hmm.. I don't think that would solve it though.
19:37 < URobots> ah well -- thanks for responses Bull, mazop and dpatton.
19:37 < dpatton> URobots: check with mashi - I know that in one of our conversations about 'terrain problems', he said that he had done something like "disabled terrain sidewalls", and it made it easy to see the problem, because the sky showed through
19:38 < URobots> dpatton - thanks. I'll come the logs for "sidewalls". 
19:38 < URobots> <comb>
19:39 < dpatton> URobots: don't bother - that was in a private chat
19:39 < URobots> ah.
19:39 < adamhill_work> ok, i gotta ask what all the icons are to the left of the LM in that shot, especially the Illuminati pyramid :)
19:40 < URobots> haha... I knew it
19:40 < adamhill_work> maybe pinky and the brain are alot further along than i thought
19:40 < URobots> all of the dev discussion wouldn't interest you
19:40 < URobots> but.. the moment I post a screen shot with new icons
19:40 < URobots> BAM! there's adam!
19:41 * Bull_[UK] is interested in the time thing, looks cool
19:43 < URobots> thanks. very early stages. might be of interest/relevance to WW (punt?) once we get it stable
19:44 < URobots> made a version of QTS that supports time and is backwards compatible with existing QTS data structure layout
19:45 < Bull_[UK]> nice
19:46 < URobots> I would say more, but the CIA-6 is listening
19:46 < Bull_[UK]> hehe
19:46 < URobots> :-) 
19:47 >> dpatton is now known as dpatton_away
19:51 < URobots> mashi -- if you ever make it back to this discussion, I have "urobots" tagged to give me a jolt of elecricity on my left pinky.
19:51 < mazop> :-D
19:52 < mazop> btw. URobots: i like your screenshot too ;)
19:52 < URobots> :-) thanks - not as cool as yours though
19:52 * mazop kickes CIA-6
19:53 < mazop> and now talk about the time-thing :P
19:53 < URobots> not enough time!
19:54 * mazop kicks time 
19:54 < mazop> better now ?
19:54 < mazop> :-D
19:56 < adamhill_work> yeah I want to know about the time thing, are those production bubble-maps? :)
19:58 < URobots> the time thing is not that big a deal -- just playing around with allowing QTS tiles to have timestamps
19:58 < URobots> then you can use a timeline to selectively choose timeline sections to display
19:59 < URobots> think of the blue marble ng...
19:59 < mazop> hmmm... morphing ?
20:00 < URobots> on the time dimension? if so.. no, at least, not until adam implements it :-)
20:02 < mazop> sorry, my bad english creates sometimes confusion... for me as well as for others :)
20:02 < adamhill_work> oh, so a QTS version of WMS-Time
20:02 < adamhill_work> cool
20:03 < URobots> yup
20:03 < URobots> but again - work in progress. 
20:06 < adamhill_work> if you didnt hear I got Refreshable Layers working (load the .xml from a URL instead of static files)
20:07 < Bull_[UK]> did you commit it yet?
20:08 < adamhill_work> i still need to figure out where to stick the timers and see how ugly delete layer/add layer looks
20:09 < Bull_[UK]> cool
20:10 < adamhill_work> if WW is walking the active layer list at framerate speeds, i might stick it there, but am wary about adding overhead to the renderloop that has a granularity of seconds
20:13 >> #worldwind-dev JOIN f0urtyfive (n=noone@pcp02538003pcs.crosky01.pa.comcast.net)
20:15 >> #worldwind-dev JOIN dumdumhead (n=8fe85699@worldwind/nasa/Dumdumhead)
20:15 < URobots> thanks
20:16 < URobots> I assume  you saw my earlier writings on options.
20:16 < URobots> Mashi also seems to be hitting the question on struts
20:16 >> #worldwind-dev JOIN nhv (n=nhv@dsl0-1.cape.com)
20:16 < dumdumhead> i figured he was if he was trying to terrain-map blue marble (and have it look right with landsat on top of it)
20:17 < dumdumhead> i saw the screenshots and obviously recognized the issues (since I had to solve them in 1.3.3.1)
20:17 < URobots> I have multiple (sometimes 10+) QTS layers rendered on top of each other
20:17 < URobots> I branched from 1.3.3
20:17 < URobots> groking your earlier comments
20:17 < URobots> "but u have to implement "intelligent struts" that are smart enough not to render themselves of there is a layer already underneath
20:18 < URobots> "QuadTile also infinitely refines itself to make sure that the mesh is always consistent among the multiple QTS layers"
20:18 < dumdumhead> right now, the struts don't render if the layer is < 255 opacity
20:18 < URobots> yeah, got that. 
20:19 < URobots> but do you programatically check to see if the mesh surface has been textured, or just check opacity?
20:19 < URobots> (I can find out by looking in the code too).
20:19 < dumdumhead> i check opacity
20:19 < URobots> ah. cheater.
20:19 < URobots> :-)
20:19 < dumdumhead> resourceful coding =)
20:20 < URobots> actually...
20:20 < nhv> once you have your lowest res tile extent can't you search the active layer list from the highest res to the lowest res and fill in the mesh that you want and only have the textures that you can see render themselves
20:20 < URobots> the struts are rendered with the mesh
20:20 < URobots> so do you klunk through the imageaccessor to determine opacity
20:20 < URobots> ?
20:20 < dumdumhead> so I've been wrestling with the concept of a "single-unified mesh" or an enhancement on our current disjoint mesh system for version 1.5
20:21 < dumdumhead> opacity of the QTS "Opacity" property
20:21 < dumdumhead> nhv: I did that in my prototype 1.4 renderer that used a singluar unified mesh
20:22 < dumdumhead> worked okay, needed some polish, and for some reason, some people couldn't get it working
20:22 < URobots> yeah - but that's on the texture side of things. I'll take a look. I tried turning my QTS layers opacity down, with no results
20:22 < nhv> right a litle bookkeeping helps
20:22 < URobots> but I think I branched just before final 1.3.3.1 checkin
20:22 < ShockFire> waaaaahhh!!!! what happened in here!
20:22 < nhv> URobots why do you have so many layers
20:23 < nhv> at one time
20:23 < ShockFire> people haven't talked in here for like half a year
20:23 < URobots> my gut doesn't like the single unified mesh - we should be relying on the GPU to do its work for us
20:23 < URobots> SF - my fault
20:23 < dumdumhead> URobots: btw, u should have cvs write access now
20:23 < URobots> ddh - graci
20:24 < dumdumhead> the single mesh eliminates the need for zbuffer clearing
20:24 < URobots> nhv - I need so many layers because we are allowing people to scroll through time and datasets from multiple sources
20:24 < dumdumhead> I'd actually like Nowak's opinions on mesh rendering as well, he's no slouch in 3D graphics
20:24 < nhv> right but why rendr them all at the sam time  ?
20:25 < URobots> ddh - yes - but you are effectively doing Zbuffer on the CPU -- when it is better done in the GPU
20:26 < dumdumhead> I'm still a newbie in shader writing, so I'm not sure what can be done on the GPU (assuming u only have VS 1.0)
20:26 < dumdumhead> and VS 1.0 is GeForce3 or above I believe
20:26 < dumdumhead> so that cuts out a lot of our 'audience'
20:26 < URobots> yeah, understood, hard tradeoffs
20:26 < URobots> I pointed mashi to Hoppe's vertex shading implementation this morning
20:27 < Nowak> dumdumhead: nah, my old hf2mx had vertex shaders
20:27 < Nowak> dumdumhead: and on even older cards they can be emulated
20:27 < dumdumhead> i do plan on working on special effects that higher end graphics cards can take advange of, but i can't make a core feature (the terrain renderer) depend on such a high-end feature (this year anyways)
20:27 * Bull_[UK] thinks ww should have 2 modes, pretty/compatible
20:28 < Nowak> but i dont see anything in nww that would benefit from vertex shaders ...
20:28 < dumdumhead> I'm well aware of Hoppe's work, but I don't see a good correlation to what we do
20:28 < adamhill_work> i just bought a 6200 for 80.00 and it has shader 3
20:28 < dumdumhead> pci-x?
20:28 < URobots> just a quick clarification though -- if you don't clear out your zbuffer, and then render a texture using the identical vertex points, you shouldn't have any z-fighting
20:28 < adamhill_work> nope AGP
20:29 < URobots> ddh - on hoppe's, the correlation was strictly on his vertex shading algo. 
20:29 < dumdumhead> URobots: correct, but we don't have identical vertices with our current disjoint system...the singular mesh idea would be considered identical vertices
20:29 < adamhill_work> the on motherboard board Intel 990's series has Shader 3,. iirc
20:29 < Nowak> URobots: but then whats the point in rendering the previous texture if youre going to overwrite it in next pass ?
20:30 < URobots> ddh - disjoint? I'm seeing a common TerrainAccessor 
20:30 < URobots> shared by all
20:30 < dumdumhead> the TerrainAccessor is only used to get a elevation from a lat/lon, it's not part of the mesh system
20:31 < dumdumhead> but the problem is that the QTS layers are not defined in a single well-defined grid, they can be arbitrarily defined
20:31 < URobots> ddh - right - but it provides the Z for the vertex. the x and y are standard (or at least nearly so) with the QTS gridding
20:32 < dumdumhead> the x and y are vary across different QTS layers (depending on the LZTS)
20:32 < URobots> nowak -- if you have multiple layers that have translucent areas (where no data exists), you need to be able to see through them
20:32 < URobots> ddh - ahh... I've been making them consistent. 
20:33 < URobots> ddh - didn't realize.. until I wrote "(or at least nearly so)" :-)
20:33 < dumdumhead> we could "enhance" QTS to use a singular well-defined grid, and have different QTS layer communicate to make sure rendering is consisten
20:33 < URobots> bingo -- that's what I've been trying to do
20:33 < URobots> butm I don't have to make the QTS layers communicate
20:34 < dumdumhead> it's not a small job though, things have to appear fast and efficient to the user
20:34 < URobots> just trust the GPU to do zbuffering correctly
20:34 < URobots> very very insightful. Excellent discussion thus far. graci, graci
20:35 < URobots> I don't think you have to have the QTS layers communicate if they are drawn to the same common global grid
20:35 < dumdumhead> QTS deserves a major revision (very soon, but maybe not for v 1.3.4 unless we can think of something fairly simple)
20:35 < URobots> and most users won't have more than a few layers visible (except for idiots like me)
20:35 < dumdumhead> I actually want to merge ImageLayer and QTS
20:36 < URobots> It seems like if you just provide a global terrain accessor with a constant grid, you'd be fine
20:36 < dumdumhead> well, u must not confuse the role of the terrain accessor, it's only purpose to to provide an elevation value for a specific lat/lon
20:36 < URobots> DDH - yeah, it needs to be done. You should see what I've had to do -- effectively generate QTS's on the fly. 
20:37 < URobots> yes -  sorry. I should be saying...
20:38 < URobots> provide a *Mesh*accessor that provides a standardize lat,lon,z for every request and will dynamically build itself to be one level of resolution beyond the BIL for the area
20:38 < dumdumhead> sorry, i have to go out for a meeting, but just keep the dialog going, i'll catch up later
20:39 < URobots> thinking on the fly, so I may be missing something. But it is effectively what I've been hacking around.
20:39 < URobots> ddh - thanks for the input
20:39 < URobots> or I really should say, help
20:39 < URobots> Nowak - did you have any comments?
20:42 < nhv> why don't you guys just have a single active texture layer
20:42 < nhv> build it up from you multiple layers at texture load time
20:43 < nhv> multipass only at texture load  not at texture draw  :-)
20:43 < URobots> <nhv> once you have your lowest res tile extent can't you search the active layer list from the highest res to the lowest res and fill in the mesh that you want and only have the textures that you can see render themselves
20:43 < nhv> absoutely
20:43 < nhv> but it is easier to do this at texture oad time
20:43 < URobots> yeah... it seems like we are discussing two ways: 
20:43 < nhv> and faster too
20:44 < nhv> maybe *much* faster 
20:45 < URobots> Method A) have an infinitely zoomable single-source Mesh that owns the vertices. Textures are then applied to it. GPU handles blending, but textures get redrawn
20:45 < adamhill_work> so right now WW loads all the texture for all the layers that are 'on' and lets the render pipeline sort it out?
20:46 < URobots> Method B) have a common single-source Texture that Textures are applied to, and the CPU handles the merging of the textures. It then makes a single texture apply to the mesh, building it in the process
20:47 < nhv> B) could still be a unified mesh
20:47 < URobots> nhv - I don't think it would be faster if you have alpha channels in your textures
20:47 < URobots> nhv - yeah, you're right. You'd have to almost...
20:48 < nhv> sure it would as the active texture only needs to be created once  not every frame
20:48 < nhv> er once every time the texture layers changed
20:48 < nhv> but that is a lot less often then every frame  :-)
20:49 < nhv> and you onluy need keep one set of texture on the card  !!!!
20:49 < nhv> the 'active' texture
20:49 < Nowak> nhv: not realy
20:49 < Nowak> nhv: consider opacity slider
20:49 < nhv> which is really the composite of all the active layers
20:50 < URobots> processing.. I see your point...  but my intuition is still banging on my head
20:50 < nhv> Nowak  good point  every thing is a trade off 
20:50 < Nowak> nhv: you would have to keep source textures and the big one in ram
20:50 < Nowak> nhv: unless you do this on cpu but then it would be painfully slow :D
20:50 < nhv> or reload layer texture from non card memory to card
20:50 < URobots> Nowak - exactly. Especially alpha channel'd tiles
20:51 < Nowak> however, you could do some smart caching
20:51 < nhv> you still don't change opacity that often  frame wise speaking but you have a point
20:51 < URobots> Nowak - thanks. I was beginning to loose concentration :-)
20:51 < Nowak> like when you change opacity it is realy A + B = C
20:51 < Nowak> so you prebuild A and B and then work on it, not every layer
20:51 < nhv> I hope you are smart cacheing all texture in main mem
20:52 < nhv> it really isn;'t that slow to bring texture across the card bus esp if they are in a compressed format
20:52 < nhv> like st3
20:52 < Nowak> nhv: im realy realy realy against compressed formats ;)
20:53 < nhv> understan 
20:53 < URobots> And we have plenty of texture room 
20:53 < Nowak> theres just nothing good enough to compare with jpeg
20:53 < adamhill_work> from the dude that compresses the heck out of tiles! :)
20:53 < nhv> but your program will be 2/3 rds speed
20:53 < URobots> yup
20:53 < URobots> that's why we have new computers :-)
20:53 < nhv> but sometimes you want quality
20:54 < adamhill_work> give the user a switch quality/fast
20:54 < URobots> you'd get better quality. 
20:54 < Nowak> nhv: i say keep currently used textures on card, recently used in ram and throw anything else out :P
20:54 < nhv> well I program to teh geForce2 family of cards  :-)
20:54 < URobots> Look at how many of you are using alpha channels
20:54 < adamhill_work> you might want to turn all compreesion off for printing
20:54 < nhv> Nowak yes that is what I was saying
20:55 < nhv> but all you need is the active composite texture  :-)
20:55 < nhv> on the card
20:55 < nhv> so prioritize that
20:55 * Nowak wish gfx cards could read jpeg :D
20:56 < URobots> so in the mean time, I'm going to get all my QTS data to be of consistent tiling as the BlueMarble, disable zbuffer clearing between QTS renders and sacrifice another dead chicken
20:56 < nhv> bah jpeg s@!ks
20:56 < Nowak> well, they do but its wired to screen output only, you cant push it to texture or cpu :D
20:56 < URobots> I think that might work
20:57 < nhv> urobots  sounds like a plan
20:57 < adamhill_work> well with DX10 we will have demand paging of textures... finally
20:57 < adamhill_work> and .0001% of the marketplace
20:57 < nhv> I would even say that you should make base tile 90*x90*  and a power of 2 on a side
20:58 < URobots> yup
20:58 < nhv> or even 180x180 is better
20:58 < URobots> I've been doing 1024 :-)
20:58 < Nowak> nhv: its 360x360 and 72x72 in my case :D
20:58 < nhv> then you start with 2 hemispheres  tiles  and left shift from there
20:59 < nhv> bah you are wasting a lot 
20:59 < nhv> :-)
20:59 < Nowak> lol ?
20:59 < URobots> But I'm ordering the best damn card I can find tomorrow :-)
21:00 < Nowak> you mean im wasting 256x512 pixels area on level 0 ? :P
21:00 < nhv> hope you have > 5K US
21:00 < nhv> yes
21:00 < Bull_[UK]> :D get me one too urobts
21:00 < URobots> And harddrives are cheap
21:00 < adamhill_work> i still want to know why Nvidia's stutter and ATI's do not
21:00 < nhv> ask NVIDIA
21:00 < URobots> Better to spin around the drive with preprocessed imagery than waste CPU/GPU time processing it
21:00 < nhv> much
21:01 < nhv> get a raid with many spindles
21:01 < nhv> if you want fast disk read
21:02 < adamhill_work> at siggraph we talked to the some of the dev relations people and they told us to send them the code with an brief problem statement, i dont think chris or randy ever did
21:02 * URobots running out the door to get to a meeting
21:02 < nhv> ciao
21:02 * URobots thanking all
21:02 < adamhill_work> thanks work waking up the channel :)
21:03 >> #worldwind-dev PART nhv (n=nhv@dsl0-1.cape.com) ()
21:03 < URobots> just don't tell the people at punt-dev :-)
21:03 < URobots> I say, as nhv leaves! :-)
21:03 < URobots> sorry, nhv
21:05 < Bull_[UK]> adam - yeah we probably should have nagged him more
21:05 * Bull_[UK] gets out mr.stick
21:16 * TheBean reads and gets thoroughly confused
21:17 < Bull_[UK]> hehe me too
21:27 >> #worldwind-dev PART mazop (n=mazop@dsl-234-27.utaonline.at) ()
22:12 >> dpatton_away is now known as dpatton
22:29 >> SignOff: f0urtyfive () [#worldwind-dev]
22:38 >> #worldwind-dev JOIN f0urtyfive (n=noone@pcp02538003pcs.crosky01.pa.comcast.net)
22:42 >> SignOff: dpatton (Excess Flood) [#worldwind-dev]
22:42 >> #worldwind-dev JOIN dpatton (n=dpatton@S01060011950c1533.vc.shawcable.net)
23:07 >> #worldwind-dev JOIN T_Servo (n=chatzill@205.208.133.221)
23:29 >> SignOff: dumdumhead (Remote closed the connection) [#worldwind-dev]
23:37 >> #worldwind-dev JOIN KpeCToHoCeL| (i=KpeCToHo@84.237.172.205)
23:41 >> #worldwind-dev JOIN what_nick (n=chatzill@150.101.97.93)
--- Log closed Fri Jan 20 00:00:00 2006