next »

[Eclipse]

My point was that the number is in the thousands, not millions.

also it will make your 2d game runs fast as crysis

[birdcloud]

Yes it is! You don't need all this fancy vector stuff you're thinking about! You can pre-determine all that during content creation! All you have to do is convert it into pure triangles and send it to the GPU! 

Approximating Bezier curves is not the lightest of operations, no. All I can say to that is... So don't use them excessively. The algorithm I have here takes ~50 multiplications per curve and a few additions per point per curve (quadratic, naturally). (actually, I'm surprised it's not heavier than that!)

That's not resolution independence! Using enough triangles to make a shape bounded by Bezier curves look smooth on computer monitors isn't enough! Output to a billboard display or a bank of monitors, say, and the approximation is obvious and an eyesore. This may seem a pedantic distinction, but it shows your solution is not different in kind from the downscaling of very large textures.

Furthermore, approximating very detailed shapes for rendering at small sizes is not easy. Try to triangulate the shapes from TTF font and render legible text at 8 or 10 pt! This problem applies to any small objects including character sprites and simply requires laborious, by-hand hinting.

[Core Xii]

That's not resolution independence! Using enough triangles to make a shape bounded by Bezier curves look smooth on computer monitors isn't enough! Output to a billboard display or a bank of monitors, say, and the approximation is obvious and an eyesore. This may seem a pedantic distinction, but it shows your solution is not different in kind from the downscaling of very large textures.

I already told you that approximating Bezier curves during run-time isn't all that expensive. If you know the exact zoom levels of the game you could even do it during load-time, problem solved, resolution independence achieved.

[Ivan]

It's not the cost of approximating curves, it's the amount of vertices required to build really detailed curves at high resolutions.

[Zaphos]

I still think this paper is pretty neat: http://www.cs.columbia.edu/cg/mts/

(not actually recommending it!  it sounds like the approach you've already settled on is fine )

If you want resolution independence, like I've said, vector is the only way to achieve that. If you don't want to use vectors, then you can't have resolution independence. Simple as that.

Hmm, I don't think fractals count as vectors.  If you want to be technical (and it sounds like you do?) then I would say you just need any procedural way of generating detail, which implies a much larger domain of techniques than 'vectors' (at least in how I use the word!).

[Core Xii]

It's not the cost of approximating curves, it's the amount of vertices required to build really detailed curves at high resolutions.

If the person is running such high resolutions, I would expect him to have the GPU to back it up. And you can always decrease the quality if it's too much for your system to handle.

Hmm, I don't think fractals count as vectors.  If you want to be technical (and it sounds like you do?) then I would say you just need any procedural way of generating detail, which implies a much larger domain of techniques than 'vectors' (at least in how I use the word!).

I was wondering about that myself. But it's not really possible to procedurally generate sprites - Textures maybe, but textures have fractal elements - Sprites don't. So although you can procedurally add detail to a vector sprite, you can't outright generate one.

[Zaphos]

Hmm, I don't think fractals count as vectors.  If you want to be technical (and it sounds like you do?) then I would say you just need any procedural way of generating detail, which implies a much larger domain of techniques than 'vectors' (at least in how I use the word!).

I was wondering about that myself. But it's not really possible to procedurally generate sprites - Textures maybe, but textures have fractal elements - Sprites don't. So although you can procedurally add detail to a vector sprite, you can't outright generate one.

Note that fractals were just one example of procedural elements that aren't vectors.  Implicit surfaces would probably also count, as would more randomized elements, etc.  Anyway, of course you can also procedurally add detail to a raster sprite (or any image) as well.

[bigpants]

They had an interesting solution over on gamedev:
http://www.gamedev.net/reference/snippets/features/dx3d2dIndieRes/
I haven't tried it myself, but it looks very interesting.

[Core Xii]

They had an interesting solution over on gamedev:
http://www.gamedev.net/reference/snippets/features/dx3d2dIndieRes/
I haven't tried it myself, but it looks very interesting.

That's just stretching it up? Hardly quality.

[bigpants]

For anyone else not obsessed with vector graphics, you might consider reading the article where the author talks about the inherent problems of "just stretching it up" and provides a solution to them. While Core Xii is quick to dismiss it as "hardly quality", I'm not sure how it could be any better. While the author doesn't take Core Xii's theoretical "make everything vectors regardless of how complicated" approach, he does provide screenshots and actual working code to backup his idea. I look forward to Core Xii doing the same.

[Zaphos]

I'm not sure how it could be any better.

There are plenty of ways of automatically increasing resolution beyond basic linear interpolation.  There are the 2xsai-style methods, for example, and the texture synthesis-based approaches referenced and expanded by the paper I linked earlier.  Or you could automatically convert to a diffusion curves representation ala http://artis.imag.fr/Publications/2008/OBWBTS08/ first, and render with diffusion curves (to pick another random example ...).  Generally the linear interpolation is not considered highly, in terms of quality, because it looks blurry and the underlying pixels still show through.  It is fast and easy though!

[Core Xii]

There are the 2xsai-style methods, for example

They are not resolution independent, they only work up to 2 or 3 times larger.

Or you could automatically convert to a diffusion curves representation ala http://artis.imag.fr/Publications/2008/OBWBTS08/ first, and render with diffusion curves

Note the title at the top: "Diffusion Curves: A Vector Representation for Smooth-Shaded Images"

It's not a technique to make raster images resolution independent, but rather a vector graphics implementation. Sure you can convert a raster image with it, but you might as well just start drawing with vectors from the get-go.

[Zaphos]

There are the 2xsai-style methods, for example

They are not resolution independent, they only work up to 2 or 3 times larger.

I didn't say resolution independent there ... but anyway, obviously if you go 2x you can go 4x & 8x and so on.  And then downsample to whatever you like from there.  Not that I'd necessarily recommend it.

Note the title at the top: "Diffusion Curves: A Vector Representation for Smooth-Shaded Images"

It's not a technique to make raster images resolution independent, but rather a vector graphics implementation. Sure you can convert a raster image with it, but you might as well just start drawing with vectors from the get-go.

I was aware of the title   I was thinking specifically of the part of the paper on automatic vectorization, which is, of course, a technique that makes raster images resolution independent.

Obviously there are reasons to start with a raster image, instead of drawing with vectors from the start.  For example if you are starting with a photograph ...

[BorisTheBrave]

I was aware of the title   I was thinking specifically of the part of the paper on automatic vectorization, which is, of course, a technique that makes raster images resolution independent.

Obviously there are reasons to start with a raster image, instead of drawing with vectors from the start.  For example if you are starting with a photograph ...

I think this is what Core Xii is complaining against. Automatic vectorization is not a magical technique for making raster images fully resolution independent. It is replacing raster graphics with vector ones, in a very lossy manner. You would never use it purely as a technique to gain full resolution independence, as your vectorized photo would look different even when viewed at the original resolution.

[Zaphos]

Did you look at the results in the paper?

Anyway, the point was not to recommend any particular technique, just to say that there were more things out there than linear interpolation.

[BorisTheBrave]

Yes, I did. They are truly beautiful, and fairly good recreations. The dolphin in particular looks like it has been digitally painted, not vectors. But they are not mistakable for the original photos, let alone being pixel perfect.

[Zaphos]

I don't suppose it's always necessary to be pixel perfect, especially if your goal in the first place was to fabricate details beyond what the pixels provided.  Of course it's not a general scheme, but I like the look of the auto-vectorized diffusion curve stuff.

[Gravious]

I know which is better

[Gravious]

:D