L3DT users' community
Large 3D terrain generator

Scalable Vector Graphics (SVG) - An idea

Correspondence concerning plugins and scripts; development, use, bugs and ideas.

Scalable Vector Graphics (SVG) - An idea

Postby Shealladh » Mon Jun 11, 2007 6:29 am

I recently came across the Scalable Vector Graphics (SVG) file format and got thinking.

I have been an avid user of Fractal Terrains and Campaign Cartographer, in doing so all of my maps are in these formats for the topography. So my delema is that I need to convert the Vector Files so that I can use them in L3DT.

Option 1: Vector plugin that supports sub-file formats, ie. a mini plugin for the plugin with SVG being one type (others are SVGZ, using compression)

I am searching for the FTW and FCW format data so these could be added as sub-file formats. I have them somewhere :(

Option 2: A seperate utility to convert the formats I need, which is a very long drawn out process and my reason for posting this.

Option 3: Somthing I haven't thought of, maybe you could help me out?


Now not being a programmer, I am looking at this as a way of making vectors available to L3DT and the added support for animations alongside the SVG's allows for experimentation or could even be used as an Undo fuction within L3DT?

So I am asking you all what possibilities could be used for a flexible plugin system and also what enhancements are allowable via SVG?
I take solice from the fact that I know nothing...compared to the rest of the world.
Shealladh
Contributing member
 
Posts: 49
Joined: Fri Sep 29, 2006 1:52 pm
Location: Melbourne, Australia

Postby Shealladh » Mon Jun 11, 2007 6:31 am

I just had another idea too...


If this was feasible then we could also use the animation feature of SVG to have historic landscape changes over time too.

Just an idea...
I take solice from the fact that I know nothing...compared to the rest of the world.
Shealladh
Contributing member
 
Posts: 49
Joined: Fri Sep 29, 2006 1:52 pm
Location: Melbourne, Australia

Postby monks » Wed Jun 13, 2007 9:20 am

Yes, I think any movement towards vectors is a good thing: svg, ai, shp because as you say Shealladh, you get to hook up with more GIS oriented apps, map tools, etc. I also use Fractal Terrains (fantastic program ahead of its time). :)
Vectors could be used for contours within L3DT.

If this was feasible then we could also use the animation feature of SVG to have historic landscape changes over time too.


Related to this idea:
http://terrain.cg-arts.org/forum/index.php?topic=93.0


monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby Shealladh » Wed Jun 13, 2007 1:36 pm

monks wrote:Yes, I think any movement towards vectors is a good thing: svg, ai, shp because as you say Shealladh, you get to hook up with more GIS oriented apps, map tools, etc. I also use Fractal Terrains (fantastic program ahead of its time). :)
Vectors could be used for contours within L3DT.

If this was feasible then we could also use the animation feature of SVG to have historic landscape changes over time too.


Related to this idea:
http://terrain.cg-arts.org/forum/index.php?topic=93.0


monks


Thanks for the link Monks, I've cleared most of the clutter in my life and am moving back to what I want to do. So look forward to dusting off L3DT and my other stuff 8)
I take solice from the fact that I know nothing...compared to the rest of the world.
Shealladh
Contributing member
 
Posts: 49
Joined: Fri Sep 29, 2006 1:52 pm
Location: Melbourne, Australia

Postby Aaron » Tue Jun 26, 2007 1:14 pm

Hi All,

For reasons of simplicity, fidelity and space efficiency, 'undo' is being handled with the native formats (DMF for design map, HFZ for heightfield, WMF for water, PNG for attributes, JPG for normals/light/texture map). Also, animation could probably be better handled in raster formats like MNG (motion PNG) or even AVI. It doesn't make a lot of sense to store raster data (maps in L3DT are explicilty raster-based) as vectors, as you're just blowing up the file size for no greater accuracy.

However, I can see some benefits for supporting SVG for importing terrain designs. What worries me though is that SVG is too broad in scope, and that there would not be a single way, or even a small number of ways, to interpret the vector files. Each program, and maybe even each user, might use a different convention or key to encode their designs as SVG. That would make plugin maintenance rather tedious, as some poor plugin developer would have to encode, test and document support for every different convention, in addition to writing one or more rasterisation algorithms. I may change my mind here if you can nail-down the usage model, and maybe post some example files.

Cheerio,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby monks » Tue Jun 26, 2007 5:54 pm

This has come up with World Machine too. The main goers seem to be svg, ai and shp. You want to be able to go between say industry standard apps like Max; shp would give you a workflow into the whole GIS world.
The problem is, to get the most out of them, you ideally want a vector format which supports z info, either natively as does shp, or via per vertex colour. As far as I know neither svg or ai supports that.

I would recommend shp as one format to support, one could find a route shp -> ai through another app.

Do you think we could/should work something out, even a new file format (like hfz), on the TS? I now that World Machine may require it. Also, Wilbur is projected to have vectors *at some point*- I can't say of course, but it's definitely on Joe's 'roadmap'.

monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby Aaron » Thu Jun 28, 2007 12:30 am

Hi Monks,

The problem is, to get the most out of them, you ideally want a vector format which supports z info, either natively as does shp, or via per vertex colour.


Storing Z info as a vertex colour would be a disaster in terms of loss of precision. Height data really should be stored in at least 12bit precision.

My reading on the SHP format (based on Wikipedia, I'm afraid) indicates that SHP is not suitable for topological (i.e. height) data. What, then, would be the purpose of SHP support in L3DT?

Do you think we could/should work something out, even a new file format (like hfz), on the TS?


Before I'd commit to yet another format I'd need to be convinced of the usefulness. Exactly what data do you wish to represent as vectors, and what do you intend to do with it? It's really not the case that I do some clever programming and then L3DT "has vectors". Rather, every usage case has to be explicitly programmed. That's why I keep asking "what do you want to do with them?"

Cheers,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby monks » Thu Jun 28, 2007 2:03 pm

Storing Z info as a vertex colour would be a disaster in terms of loss of precision. Height data really should be stored in at least 12bit precision.


The vectors wouldn't be used in the same way as raster data. Vectors with z always use interpolation anyway- so loss of accuracy is built in. It's just a different way of working.

My reading on the SHP format (based on Wikipedia, I'm afraid) indicates that SHP is not suitable for topological (i.e. height) data. What, then, would be the purpose of SHP support in L3DT?


You would need an interpolator as well- as I've said before. Once you swallow the interpolation and accept the loss of accuracy as potentially useful for eg, design sketching, there's a number of different uses.


Before I'd commit to yet another format I'd need to be convinced of the usefulness. Exactly what data do you wish to represent as vectors, and what do you intend to do with it? It's really not the case that I do some clever programming and then L3DT "has vectors". Rather, every usage case has to be explicitly programmed. That's why I keep asking "what do you want to do with them?"


Vectors has the advantage of scale independence. So for polyline networks, it's very useful. So you would have rivers and roads (and any other map type data you'd want to add) from that. The raster representation of rivers is a real problem when you start to factor in scalability.
You could transfer z between between terrain and vectors and vice versa. Just a thought.

Then of course, there's drawing contours- that's why I keep saying "contours". //grin

monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth

Postby Shealladh » Fri Jun 29, 2007 10:04 am

I'm with you on that Monks, rivers and other detailing specifics would benefit from vectors, but my main reason for getting in on the act here is for sheer Topography Contours as well.

SVG may not be the best for everything, yet what if the format expands to include those references (see above posts) about detail loss and such.

We may never see the end of raster imaging, but the quicker the majority of data is stored as vectors, the better us builders will be.

I do consider this to be on par with 2D/3D Animation.

2D (or raster with regards here) is dying and new methods are needed to build the bigger/better terrain features we all dream of.

3D (or vectors) is the new and is just starting to scratch the surface with what can be done with them. The more ideas put forward, the faster they will become standard and universily accepted method of doing things.

Think of what TRON's SFX designers where trying to sell when they made their movie, or Lucas trying to justify SW's budget on CGI effects.

I feel this is the Next Gen of landscaping and model making in the world of computer rendering. Once I can get my things together and rebuild another team of people, L3DT is shaping up to be my BEST BET of the tools to use. It just needs vectoring :wink: now....
I take solice from the fact that I know nothing...compared to the rest of the world.
Shealladh
Contributing member
 
Posts: 49
Joined: Fri Sep 29, 2006 1:52 pm
Location: Melbourne, Australia

Postby Aaron » Mon Jul 09, 2007 1:49 am

Hi All,

Vectors with z always use interpolation anyway- so loss of accuracy is built in.


That's non sequitur. Interpolating between vertices does not reduce the accuracy of the data. However, encoding vertex heights using 8-bit colour depth does reduce accuracy; it mangles the vertex z coordinate, and quite severely so. That's why we don't use bitmaps to store heightfields, and why we shouldn't use SVG for the same.

As for SHP support for roads, rivers and other linear features: quite reasonable, and on the to-do list.

Contours: Doesn't Wilbur do this already? I know it's less convenient, but can you rasterize your contours in Wilbur and then import the TER/whatever?

We may never see the end of raster imaging, but the quicker the majority of data is stored as vectors, the better us builders will be.


I don't think we should get too carried away here. Would you want to store a photograph as a vector image, and if so, why? It won't be any more scalable, but it will be a couple of times larger on disk, and it will take your computer a longer time to re-rasterize the image to display on your monitor (a raster device). Vector storage is effective for sparse data like geometric shapes (lines, polygons, etc) or other algorithmically reducible features (gradients, text characters, etc). Vectors are not effective for irreducible, dense gridded data like real images, where raster formats are superior. Even in 3D there are cases where raster formats are superior (e.g. voxels in medical tomography). It's not a case of "vectors are better, so let's forget about raster". Vector representations are better sometimes, not always.

So, in summary; I'm happy to add SHP support for sparse geometry (rivers, roads, etc). However, for dense geometry (e.g. the whole heightfield) or for image data (e.g. textures), vector formats would give no benefit that I can see, or has yet been articulated in this thread. Building raster terrain from vector contours may indeed be an effective use of vector data, and interested programmers are welcome to develop a plugin to that end. Whether I do so personally is an issue of time and priorities, and I don't consider the case to be imperative at this point (however, from the ME-DEM point of view, I can see that it would be imperative.)

Cheerio,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby monks » Mon Jul 09, 2007 10:17 am

That's non sequitur.


I think the textbook response is 'Whatever' :lol:

Interpolating between vertices does not reduce the accuracy of the data.


Neither does reading between the lines on ocassion :wink: I meant 'is less accurate', not 'loses accuracy'.

However, encoding vertex heights using 8-bit colour depth does reduce accuracy; it mangles the vertex z coordinate, and quite severely so. That's why we don't use bitmaps to store heightfields, and why we shouldn't use SVG for the same.


We're agreed on that then. My point is, sometimes you don't need that much accuracy, for terrain.

As for SHP support for roads, rivers and other linear features: quite reasonable, and on the to-do list.


Great!, I hope your userbase sees many benefits from vector data within L3DT. :)

monks
monks
Oracle
 
Posts: 292
Joined: Tue Nov 22, 2005 10:38 pm
Location: Middle Earth


Return to Plugins and scripts

Who is online

Users browsing this forum: No registered users and 2 guests

cron