tag:blogger.com,1999:blog-19727408.post134212551901977647..comments2016-07-20T09:43:51.417-04:00Comments on X-Plane Scenery Blog: Why We Must Edit the Source DataBenjamin Supnikhttp://www.blogger.com/profile/04886313844644521178noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-19727408.post-13318954026270850282008-07-20T15:27:00.000-04:002008-07-20T15:27:00.000-04:00Dan31, I still do not agree entirely.I do agree th...Dan31, I still do not agree entirely.<BR/><BR/>I do agree that orthophoto-based scenery would not be scenery that you share as part of collective work to improve the global scenery - it might require too much hardware, or too much storage, to be part of the global scenery.<BR/><BR/>BUT...you still have the same question: do you build the new DSF from source data + orthos, or the old DSF + orthos.<BR/><BR/>Now you CAN (today) make new DSFs out of old ones using PhotoSceneryX. I won't be providing this tool not only because it is not my preferred approach, but because Justin has already done it!!<BR/><BR/>But you can also make that new DSF using source data (coastlines, DEM, land use, photo placements).<BR/><BR/>I prefer this technique because:<BR/>- It lets you correct elevation as well as photo placement...DEMs are easy to get with SRTM around, and editing them is pretty straight forward as well.<BR/><BR/>- You don't pick up accumulated error from importing and rebuilding the finished DSF.<BR/><BR/>- The mesh will be allocated more efficiently if it is rebuilt with orthophoto placements, rather than simply having additional cuts burned in to place the photos.<BR/><BR/>Basically if you ONLY want to repaint orthophotos, then editing the DSF might make snese - but this technique isn't "scalable" - as soon as you want to edit the DEM, change coastlines, etc., rebuilding from source makes more sense.<BR/><BR/>We provide our land use data now to make MeshTool a workable options...DEMs and coastlines are up to you. (DEMs are easy to get...coastlines are a bit tricky...I hope to add shape-file coastlines to MeshTool someday so that you can use SWBD as a coastline source.)<BR/><BR/>Final note: the reason I say the mesh is "less efficient" is this...our mesh algorithm places more vertices in places where there is more mesh detail -- that is, lots of vertices on mountains and vey few on a flat valley. If you provide a NEW DEM and simply edit the existing DSF, because you are not reallocating the vertices, vertices might not be used in the most "interesting" places, resulting in less accuracy for a given triangle count.Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-19727408.post-50149646630759435832008-07-20T10:26:00.000-04:002008-07-20T10:26:00.000-04:00OK to share Scenery, but if I use orthophoto to ma...OK to share Scenery, but if I use orthophoto to make a scenery wich could run only with a gigabyte video card ?<BR/>Nearly nobody could use it. So no use to share this kind of data. But I need to modify the DSF to make this scenery. So we need tool to help use modify easyly the DSF.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19727408.post-77698612140941327552008-07-17T10:06:00.000-04:002008-07-17T10:06:00.000-04:00KRZ: I agree that multiple edits to a DSF from mul...KRZ: I agree that multiple edits to a DSF from multiple authors COULD be merged (with results that might be somewhere between good and lousy). But that's not my point!<BR/><BR/>My issue is that the edits are being made to a lossy derived data format and not the original source!<BR/><BR/>To use a coding example:<BR/><BR/>Users submitting the DSF edits would be the equivalent of users submitting their patches to Linux in ASSEMBLY LANGUAGE and not C.<BR/><BR/>It would be much harder to merge those patches because the "context" of the patch (assembly) would not be stable due to edits to the original source.<BR/><BR/>From a google documents perspective, it's as if you make an edit, but while you did, I converted the entire thing to French! Context - gone!<BR/><BR/>The fundamental problem is that the final cooked data (DSF) appears to change radically in a way that isn't easily predictable from mods to the sources. This is what invalidates DSF-level patches.<BR/><BR/>So the issue here isn't one of merging, it is one of de-compiling.<BR/><BR/>(And lest I get myself into even more trouble, yes, it IS possible to derive the original data back from the DSF - we could attempt to isolate the road mesh, the DEM, etc. But do we really want to do this? DSF is a LOSSY format? The result would be an increase in error bounds in the data every time we took a patch.)<BR/><BR/>If we were doing image editing, would we want our patches submitted as edits to the original layers in a photoshop document, or edits to a 50 KB JPEG that was optimized for the web?Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-19727408.post-82302384832389755122008-07-17T09:44:00.000-04:002008-07-17T09:44:00.000-04:00...it can be done ;) http://www.youtube.com/watch?......it can be done ;) http://www.youtube.com/watch?v=GfeUCT-tRJQ<BR/><BR/>or u might take a look to google docs. they do it too. but i understand that this is not something that can be implemented over the weekend. ..and its not really necessary for xplan these days. <BR/><BR/>im looking forward to the way the scenery data will be shared and what kind of version-control (& sign-in sign-out) u implement.<BR/><BR/>if that is done right the sim could benefit alot. <BR/><BR/>i still dream about a joint-venture with the google earth team since both programms work on the same thing and redundancy in such case is always wasted effort.Anonymoushttps://www.blogger.com/profile/15668721469855025283noreply@blogger.comtag:blogger.com,1999:blog-19727408.post-16674475252180119042008-07-17T09:39:00.000-04:002008-07-17T09:39:00.000-04:00y-man, this old post explains it I think:http://xp...y-man, this old post explains it I think:<BR/><BR/>http://xplanescenery.blogspot.com/2007/01/airport-flattening-untold-story.htmlBenjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-19727408.post-59353378297908876112008-07-17T09:36:00.000-04:002008-07-17T09:36:00.000-04:00Thanks for explanation.Looking forward to the time...Thanks for explanation.<BR/><BR/>Looking forward to the time we'll be able to do corrections to base DSF.<BR/>Both corecting bad sampling errors, and making "runway follows land countours" option --which I love, but had to give up on-- usable depend on this.<BR/><BR/>Would you be kind enough to give an explanation of why the airport flattening causes weird water cliffs/hills when the airport is close to shore? <BR/><BR/>Those bad water artifacts do not occur with "runway follows land countours" on, but it has its own problems like very steep taxiways, and converted scenery objects sinking/floating.Unknownhttps://www.blogger.com/profile/12310735055032541446noreply@blogger.comtag:blogger.com,1999:blog-19727408.post-83362873224356861332008-07-17T09:33:00.000-04:002008-07-17T09:33:00.000-04:00Rob wrote this:"Hi Ben,Would it be possible to est...Rob wrote this:<BR/><BR/>"Hi Ben,<BR/>Would it be possible to establish some kind of centralised database which stored only corrections (contributed by X-Plane users) to default X-Plane scenery (base mesh, objects and landclass info)?<BR/>In this way Laminal R would secure that full X-Plane installation is required and maybe limit the amount of data to store and transfer. X-Plane users could easily download (on their request) corrections from the database with a tool similar to X-Plane installer which merged local DSF with downloaded patches.<BR/>Since database supervising and solving problems with the conflicting data would require a lot of men-hours the database would be run rather by community (like x-plane.org) instead of Laminal R. I am sure that people can do amazing things if you provide them tools capable of doing this...<BR/>Would it be feasible? Rob"<BR/><BR/>Rob, I'm sorry I had to move your comment - I'm not sure which post you were trying to post to - I accidentally dumped a blank post up last night.<BR/><BR/>Anyway, the answer is basically: no. Please see today's post. We can't work with "diffs" to DSFs, we need to work with the source data - otherwise all the fixes will be lost on a regular basis.<BR/><BR/>We need to track changes to the SOURCE materials.Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.com