Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Heyworth]

I don't claim to know much about 3D... I have a very little experience with 3DSmax and texture rendering etc. I do however work with Adobe Illustrator (vectors) on a fairly regular basis.

Vectors are extremely compatible with how computer CPUs process information.
Compared with rasterization (BMP, JPG etc) the speed and scalability of a vector is MUCH FASTER!

Therefore, one thing that has always baffled me, is why the two graphic processing techniques are used together in a virtual 3D environment?
It just appears illogical (I am a layman).
Can 3D engines use vectorised textures?

Vectorised Textures
Multiple layers of coloured 2D vectors could easily be made into textures and therefore speed up the whole rendering process.
This would dramatically enhance the interaction with the environment and could also (with the right algorithms) greatly improve collision detection and effect!

Imagine two different meshes are assigned with two different vector textures (lets call it them a VT from now on)
Each VT could be 'tagged' with a certain firmness.
The firmness could depend upon how many layers of different shaded vectors make up the texture...

Example
Out of a firmness of 100... A Diamond VT is tagged at +80 meaning it consists of 80 layers and is therefore a VERY STRONG material.
80 layers in design terms is PLENTY to make a diamond texture.
Some of the layers/parts of each layer will therefore need to be invisible/semi-transparent.

A Collision Situation
A mesh is assigned with a glass texture and along comes a mesh with a rock texture...
The glass VT is tagged at a strength of +15 and the rock tagged at +50
GLASS_VT is therefore made up of 35 less layers than the ROCK_VT.
Therefore with an impact of +35, the rock simply destroys glass!
NB. Obviously the algorithms would have to account for other physics, such as speed and angle etc 

In a different situation...

Metal Chisel Blade vs Wooden Block
SSTEEL_VT_60 vs OAK_VT_40 (Oak has 20 fewer layers)
Therefore the chisel would remove 20 layers from the wooden block texture.
NB. An algorithm for speed would effect the depth of cut and therefore result in a variety of chiselled finishes.

Therefore you would VIRTUALLY SEE the different materials effecting the environment around you.

Anyway what do you think?
Am I way off with my thought processes?

LINKS
http://dl.acm.org/citation.cfm?id=1342281
http://forums.cgsociety.org/archive/index.php/t-331139.html

[cameni]

Compared with rasterization (BMP, JPG etc) the speed and scalability of a vector is MUCH FASTER!

Perhaps you are speaking about the speed from your point of view (when manipulating them), but the rendering performance and its scalability depends on how parallelizable the rendering operation is. Rendering a raster image can be done completely and easily in parallel, but rendering layers of vector data is always at least partially sequential operation, introducing bottlenecks.
Using textures is basically an optimization technique (with its shortcomings) that has to be still used because the hardware is not yet powerful enough to handle everything using vectors.

[Heyworth]

Did you know that the rasterized image format, was designed with the CRT monitor in mind? The pixels appear in the same order and pattern that the cathode ray scanned the glass. This article explains why rasterization is much slower and more problematic for 3D. http://blogs.valvesoftware.com/abrash/raster-scan-displays-more-than-meets-the-eye/

[ZeosPantera]

Aren't I glad my big 24" 1920x1200 CRT is being used...

Leave my Raster's alone!

[cameni]

Uh that's completely unrelated. Raster scan displays and raster images are different things. And there's nothing about the rasterization being slower either ...

[Heyworth]

"but rendering layers of vector data is always at least partially sequential operation, introducing bottlenecks"

Back in the days of editing Doom map files .wad - the textures (rasterised images) were preloaded (you were only allowed a certain number of them) into memory and 'texture mapped' onto the environment.

Wouldn't it be a simple case of (in the right engine) substituting one technique for the other? So VT files are preloaded and therefore do not require as much 'on the fly' rendering/processing?
I know good vector files are slightly larger than png or jpg, however GFX cards have heaps of memory nowadays and memory is getting cheaper...

I can't find anywhere on the internet to sample this. I find it hard to believe that nobody has tried it?
The only relevant information appears to come from documentation...

EDIT: CLICK HERE FOR SWIFT 3D


http://en.wikipedia.org/wiki/Raster_to_vector

http://developer.amd.com/wordpress/media/2013/02/Chapter2-Green-Vector_Textures.pdf

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.154.9948

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.2464

http://dl.acm.org/citation.cfm?doid=1342250.1342281

http://research.microsoft.com/en-us/um/people/cloop/LoopBlinn05.pdf

[Edding3000]

As you said as one of the first sentences you do not know a lot about 3D. There is no such thing as vector textures in 3d.
It is not how graphic cards work internally.
They bind textures to polygons.

[Heyworth]

No shit Sherlock!

I'm investigating the concept of binding VTs to polygons!
I was attempting to think outside the box a little!

My '3D Knowledge Box' may not be very large, however I do know the biome looks better in than in Outerra.

Unigine - Valley Benchmark - Free Download

[cameni]

Edding has a point though - it's quite problematic to discuss anything without having a bit deeper knowledge of the matter.
For example, the terminology you are using is very confusing.

Unigine Valley demo is a manually created scene. I would not call it having "biomes". There are no biomes in Outerra yet, for that matter.

[Heyworth]

I guess I'd better leave my layman box right here, I'll go and get my jacket...
I'll visit again in a few months to see how it's progressing.
All the best.

C4N

(Ciao for Now)

[Edding3000]

I guess I'd better leave my layman box right here, I'll go and get my jacket...
I'll visit again in a few months to see how it's progressing.
All the best.

C4N

(Ciao for Now)

There is no need to be pissed of about this! I'm not trying to make you look like a fool.
It would be very interesting if possible! because no longer would there be a problem with texture resolution.
But i have no idea how it would be possible to send a true vector texture to a GPU!

It's something like this: You load a 'picture' of certain format (Dds, jpg, bmp, whatever) into a DX 'texture-slot'. This texture you can 'bind' to variable in a shader, this shader has coordinates (X,Y) (0-1,0-1) and interpolates on the tex surface. (0.5,0.5) would be the center of the texture.

Its just about the architecture of directx.

But i will look into your resources a bit deeper to take a more exstensive look.

Kind regards.

[Heyworth]

So even though I didn't know the correct terminology, you did know what I was talking about 

I'm pissed with myself... Only because I can't talk like you guys.

The only way I can do it is to say... "this is roughly what I am talking about" or "this mentions something similar"

Like these links...

http://developer.amd.com/wordpress/media/2012/10/Oat-RenderingGooeyMaterials.pdf
http://freehandfuturist.com/blog/vector-textures-simple/
Is a different kind of engine needed to load an SVG into a 'texture slot'?

[Luishi5k0]

Those articles don't really have much to do with practical implementations of vectors into games. The first one is dealing with multi-layer materials and essentially amounts to subsurface scattering. The second is just some tools for graphic design (ads, posters), and the third is dealing with Illustrator once again. Illustrator doesn't load a vector image into the GPU, same with Adobe Flash. You can use hardware acceleration to have the GPU help with the drawing process, but these are just optimizations, and not texture related.

Like others have said, the architecture is just not meant to handle vector textures. I personally don't even see how there would be a great benefit to having them. Yeah vectors are smooth and you can zoom in on them, but that doesn't necessarily give it more detail. If you take an image and convert it to vectors it doesn't have more detail, it just has smoother boundaries. And that's only when you are close enough to see it. Even then, it will look unnaturally sharp. ONE thing I can think of is if you had some sort of vector outline for an alpha mask on something like a lief of a tree, that way you'd have a perfect edge to it. EVEN SO, that is not an especially good benefit. We are about at the age where textures are simply sharp enough as it is.

What IS a benefit is a procedural texture, that dynamically increases detail using noise and fractals as you get closer. In much the same way that the terrain is tessellated in Outerra. That way you could generate the texture at higher iterations of a fractal or noise map as you get closer to it. That could help remove repeating textures over a large area, like the standard grass texture over a field problem.

[XZS]

Hello, I'm adding my part of "irrelevant point" about this topic. This story of vectorial and rasterized graphics reminds me of the voxel technology, the big forgotten one, at least for me. I'm aware it would be pointless to add anything about voxel in a polygonal-based engine as Outerra, it just I'm kind of nostalgic about this technology. I would be happy to see such a powerful engine as Outerra, running on a voxel technology.

A mix of Outcast (keep in mind this game has been released in 1999!)
with a bit of the Ken Silverman's voxel engine

But no GPU today is made to run voxel, as far as I know.

[Peca]

Voxels are not as dead technology as it may look like. AFAIK Cry Engine uses voxels for terrain deformations. For inside calculationsthe terrain is kept as a voxel object and only for drawing it's transformed to polygons.