Outerra forum
Outerra Engine => Ideas & Suggestions & Questions => Topic started by: Heyworth on February 12, 2013, 01:59:19 pm
-
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://dl.acm.org/citation.cfm?id=1342281)
http://forums.cgsociety.org/archive/index.php/t-331139.html (http://forums.cgsociety.org/archive/index.php/t-331139.html)
-
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.
-
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/ (http://blogs.valvesoftware.com/abrash/raster-scan-displays-more-than-meets-the-eye/)
-
Aren't I glad my big 24" 1920x1200 CRT is being used...
Leave my Raster's alone!
-
Uh that's completely unrelated. Raster scan displays and raster images are different things. And there's nothing about the rasterization being slower either ...
-
"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://www.erain.com/Products/Plug-ins/)
EDIT: Sculptris - A Dynamic Tessellation Example (https://vimeo.com/12796457)
http://en.wikipedia.org/wiki/Raster_to_vector (http://en.wikipedia.org/wiki/Raster_to_vector)
http://developer.amd.com/wordpress/media/2013/02/Chapter2-Green-Vector_Textures.pdf (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.154.9948)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.2464 (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.2464)
http://dl.acm.org/citation.cfm?doid=1342250.1342281 (http://dl.acm.org/citation.cfm?doid=1342250.1342281)
http://research.microsoft.com/en-us/um/people/cloop/LoopBlinn05.pdf (http://research.microsoft.com/en-us/um/people/cloop/LoopBlinn05.pdf)
-
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.
-
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 THIS (http://youtu.be/ZMVz3oUCagw) than in Outerra.
Unigine - Valley Benchmark - Free Download (http://www.guru3d.com/files_details/unigine_valley_benchmark_download.html)
-
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.
-
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)
-
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.
-
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://developer.amd.com/wordpress/media/2012/10/Oat-RenderingGooeyMaterials.pdf)
http://freehandfuturist.com/blog/vector-textures-simple/ (http://freehandfuturist.com/blog/vector-textures-simple/)
Is a different kind of engine needed to load an SVG into a 'texture slot'? https://www.youtube.com/watch?v=r8LEKLzRhN0 (https://www.youtube.com/watch?v=r8LEKLzRhN0)
-
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.
-
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 Outcast - trailer (http://www.youtube.com/watch?v=DJDLuDrkcKQ#) (keep in mind this game has been released in 1999!)
with a bit of the Ken Silverman's voxel engine Ken Silverman's Voxlap Engine test game (http://www.youtube.com/watch?v=XaUt31ooCXs#)
But no GPU today is made to run voxel, as far as I know.
-
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.
-
Another 'NON-Rasterisation' engine called Brigade Engine
http://youtu.be/pXZ33YoKu9w (http://youtu.be/pXZ33YoKu9w)
What is Brigade Engine?
It seems that a lot of people are not understanding what is really Brigade, the engine I am doing pictures with.
So I’m going to type something about it.
First, Brigade is in real-time, it’s an engine for video games. It uses path tracing to render the image; instead of rasterisation like every other 3D games.
Brigade uses path tracing, which is an extension to the ray tracing algorithm capable of producing photorealistic images. It traces many rays (samples) per pixel in random directions, and then takes the average value to calculate the final color of each pixel.
Whenever a ray hits a surface, a new ray is traced from that hitpoint in a random direction until the max path depth is reached or until a Russian roulette-like mechanism kills the ray.
This way, path tracing is able to produce effects like diffuse color bleeding, glossy (blurry) reflections, true ambient occlusion, soft shadows, caustics, true depth of field, etc.
It can simulate every known material including participating media like fog, god rays and clouds and materials with sub-surface scattering for example.
Everything is physical & calculated right. No hacks whatsoever are used to create effects; I think that most of you are aware for example of Depth Of Field in random games that are just depth hacks; that’s why we have so many difficulties to apply it right or the edges are somewhat messy, doesn’t blur the alpha materials, etc…
Well, with Brigade. The artist or game designer can imagine whatever he wants without restrictions in terms of rendering, no need for hacks/ pre-bake maps (Mirror’s edge used pre-baked lighting to look so good).
Brigade brings CGI rendering to video games, and that’s why I’m very enthusiast about it. Because it runs amazingly well & it’s still in early stages.
You can check some screenshots here : https://www.facebook.com/media/set/?set=a.471466862887799.111426.198351220199366&type=3 (https://www.facebook.com/media/set/?set=a.471466862887799.111426.198351220199366&type=3)
http://icelaglace.wordpress.com/2012/09/22/what-is-brigade-engine/ (http://icelaglace.wordpress.com/2012/09/22/what-is-brigade-engine/)
http://render.otoy.com/gallery.php (http://render.otoy.com/gallery.php)
http://raytracey.blogspot.co.uk/ (http://raytracey.blogspot.co.uk/)
(http://3.bp.blogspot.com/-_BKwh8a9zgM/UPYxVtVVoPI/AAAAAAAADe0/Y5fh7iscay0/s1600/cubecity9f.png)
(https://fbcdn-sphotos-d-a.akamaihd.net/hphotos-ak-frc1/860121_540837382617413_1898443998_o.jpg)
(http://1.bp.blogspot.com/-ZaOLT2nqc_U/UM-bO2khVSI/AAAAAAAADUo/RZTUukgGk4g/s1600/clayhead11.jpg)
-
Yeah Brigade is great, but far too ahead of his time (techically), for me.
I gived a try to some public demos: on my computer with Intel Core 7 with Gforce 560M (not that bad even for a laptop in 2013), it runs very very slowly for a great result only on still image. Even in their videos (which must runs on top notch high-end computers) , you can clearly see it looks great only when you don't move the camera...
I don't say it is a dead-end, it just will be right on his time in 3 or 4 years, when everybody-computer could run it smoothly.
Beside, IceLaGlace is a nice guy :)
-
I don't know what people say. But this demo is impressive and really good. Future gaming will be amazing with these type of technologies