I am wondering why a lot of artist are still using uvs for game models and movies while ptex is available.If I am correct,I think it has been out since 2011 or so.Ptex allows u to apply textures to ur model without the need to uvmapp and its resolution independent.
I think I speaketh for all of us that uvmapping is time consuming.The time taken to uvmap could be better spent creating more stuff.I am curious why ptex isn't used for games and most movies.I am thinking maybe the current game engines-cryengine,udk e.t.c don't support it(no realtime display).Maybe next gen consoles?
Replies
It makes sence for high poly Z-brush / Mudbox meshes to be textured this way. But ultimatly the low poly mesh has to have as few UV sets and unique textures as posible.
http://ptex.us/overview.html
On top of that, every UV seam is adding extra verticies to your mesh.
I think Ptex would work if you where using something liek ID's megatexture. One texture lookup in memory, mainly used on the envornment or terrain. Somewhere where the extra mesh data wouln't make a huge dent in proformance.
Am I the only person who doesn't hate unwrapping? Or is it just that nobody uses textools or roadkill and they just hate the default unwrapping tools most apps still have?
It was made to avoid the need to worry about UV mapping and with the right tools you can project the old ptex texture onto new topology in the model (say if you change the mesh after painting)
Maybe there will be an evolution of ptex for games where it will atlas the textures into a sheet and allow different densities etc.
Maybe for authoring it'll be used and then baked at the last step into UV coords for more control.
Ultimately ptex removes boundaries and eases workflow at the cost of memory.
Since you will always want a game to look the very best for the very lowest cost then UV make a lot of sense still vs alternatives.
Even Ptex are not that great but the workflow benefits offset the costs mainly because RAM and HDD space are so cheap these days I suppose.
Or that is how I read it all when reading some original papers on ptex and it's purpose.
Dave
I can understand why some will still use uvs but with the capabilities of next gen game engines and opensubdivs(don't know if this works with games yet),its only a matter of time before ptex replaces uvs.
Currently,opensubdivs uses ptex with animation playback running smoothly.Nextgen games might be able to make use of ptex but it will probably be a confirmed feature towards the next generation consoles after ps4 and xboxone.
But most definitely,even if ptex isn't used,a kind of feature that surpasses and eliminates the need to uvmap will be developed.
+1. There is so many tools for unwrapping organic thing with one click that it is now no brainer to do.
But unwrapping technicall stuff is till boring, and tedious hard work. In 3ds max it looks like:
1. Slect All.
2. Flattern Mapping.
3. Slect edge and Stich.
4. Reapet 1-3 until you are done or died because of boredom.
Dunno. Since most people use 3d painting now (3d coat, Mudbox, modo, pick whatever you like) UV layout got the point where it doesn't need to be readble, but maximized space usage.
And after you bring it to Photoshop, you will probably end up using dDo to add details instead of painting everything from scratch.
not to mention effects, UV animation and distortion can be useful at times, and the many other tricks you can do in your vertex and pixel shaders with your uv's
Or you know, you could learn one of the few trades in 3D and be done with it? It's not exactly rocket science, even if you do model a rocket.
Also, are you guys not forgetting something? Anisotropic shaders that need UV? Normal maps with split edges? Vertex Counts? Everything else Passerby mentioned?
You will always needs UV's for some reason, big or not. For example, I really doubt for something as small as fixing maybe the holes on the nose of a character on my specular map, I'm going to load up a program like Mari, wait a minute or two to open the scene and paint away something that would have literally taken me 30 seconds tops in PS with the boot-time included.
+1 ptex where each face essentially has its own uv mapping or whatever, is really inefficient as far as vertex use goes, and anyone who works in games knows that vertex count has a huge bearing on performance.
Yes. And I used Mudbox.
https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Borderless%20Ptex.pdf
however I'd agree it ain't there yet for every-day game use, and when you have "trained" people doing regular UVs and majority of assets use that way for rendering, which is also cheaper perf-wise, it doesn't make much sense yet to use in the average game, where non-ptex content dominates.
Ain't nobody got time for that.
Only hero assets can really take advantage of 3d painting, but for most hard surface or enviroment assets, probably not worth the time. A asset may get a quick pass in a 3d painting app, but the bulk of the work is going to be with photoshop, substance designer, or dDo.
One shortcoming of 3d painting is the inability to paint tiny details with the brushes but painting on flat uvs will have u repeating paint strokes,saving and checking ur model(flipping btw photoshop and 3d app) to get features exactly where u want them.That can be cumbersome.Thats why I like Blender,u get to paint textures in ur uv editor,modify ur uvs and watch it update on ur 3d model and u can paint on ur 3d model and see the update in ur uv editor.
But are u guys saying if ptex becomes compatible for games or a technique is developed that makes uvmapping unnecessary and it does not affect game performance,u will rather stick to uvs?
Its going to be a while (probably 7+ years) before something like ptex can be used in games as one of the other members pointed out, unwrapping your models is a way to optimize poly/tri count of your models. I didn't know this until somewhat recently but the tri count of your mesh is NOT determined by the number of polys or tris in the mesh, its actually determined by your the UVs. The reason for this is due to the fact that you have to break your mesh into separate "islands" or "charts" or what have you and this increase the vert count of the mesh.
Create a simple cube for example and you'll see that it has 8 verts. Now separate each face of the cube into its own piece and see how many verts you have. Three times as many!
Now imagine if you have a "Next Gen" character model weighing in at 60,000 polys and you use a system like Ptex which essentially breakes the mesh into separate polys. You'll be left with 180,000 verts to render instead of maybe around 70,000 that you'd get from unwrapping the mesh.
Sure Ptex will save you time, but its not optimized so there's not much point until you can push so many millions of polys that it doesn't matter anymore. Hence why its used in film and not games.
I'm sure they'll figure out how to optimize it in the future and come up with a system that works in games, but you're not likely to see it until the next Next generation.
Though I'm confused - on page 30 it talks about performance impact. I think he's saying that ptex would require 30% of system memory versus 15% for uved meshes? That's still a huge performance hit. Not quite the 3 times as many verts as in my description above but still not nearly as optimized as UVs.
Seriously, we're not going anywhere with PTex, even Pixar uses it SPARINGLY, they said this mutiple times, hell, half of the stuff they do is almost like gaming, want to have a 'rope' physics solution? Use your best stuff for hero pieces (like in Monster Inc.) and the rest is either baked in or cheap simulated.
You're also forgetting that your game HAS TO RUN ON THE CONSUMERS MACHINE, the next 2 generations, or even 3 of consoles aren't going to support Ptex, so that can be easily 15 years of you doing nothing and sitting on your ass 'waiting' for something to make your work easier.
As a Dev, that a no-no, waiting on your ass for the next big engine or graphical evolution that will make your job easier is not how we progress nor it ever will be, because you won't have a position to work in at that point.
PC's might have it quicker, due to the tech evolution rate, but are you honestly going to ask people upgrade their PC's JUST for PTex textures/shaders in your game? In the last few years alone, we had a stalemate of PC tech due to consoles, and again with the rise of portable machines, this can easily add an extra 5 years to waiting for having Ptex in real-time, game engines, simply not feasible.
Sure, you could include a low-end option, WHERE YOU HAVE UV'ED MODELS, but that defeats the entire point of having Ptex, does it not? Why have it then?
You have think much bigger then simply "this will make my work faster for me" Mel, almost all of your posts are about how to cut out as much work as possible on your end and do the least amount of work in that regard, and I'm not even talking about pipeline related, I literally mean you're hoping and wishing for stuff that had to do with the consumers machine, not the Dev's and their tools.
This is unfeasible, you have to start thinking about stuff that aids/improves your Dev tools, not about some fancy tech that 80-90% of the (in this case) PC (and only market) would not be able to run without chugging in the next 10 years.
In your example breaking the model into different faces would have no impact on the vertex count since it already has smoothing splits.
I wouldn't want to use ptex because it sounds like it does some kind of automatic unwrapping which makes baking models very difficult or impossible. Vertex count increases aside, having all those UV splits along faces where you may not want any kind of split can introduce shading errors. Does ptex snap all UVs to rounded off UV coordinates? Just trying to get projections to line up perfectly across a bunch of individual triangles is going to be a problem.
Ok cool, I just assumed it worked similar to standard methods in regards to vertex count, good to know that's not correct.
So, can you give us more of an idea on what the performance impact means in the real world? That paper says 15%, but obviously that doesn't mean your game runs 15% slower, it just means that shader is running 15% slower(or 15% more memory, or whatever), and could be near inconsequential when factoring in everything else that runs in a game, right? Especially when you consider the memory savings it gives you (save some memory vs use a little more GPU power).
Though it looks like there are some painful workflow drawbacks as well, like only working with quads, and pixel stretching on non-square (ie: trapezoidal) faces.
Alec: Ptex doesn't do automatic "unwraping" because nothing is "unwraped" each quad has a unique square in the UV layout, from what I understand. But yeah, baking things like tangent space normal maps would appear to be much more difficult.
Zac: I think you're getting a little carried away honestly, Ptex can run on DX11 hardware and unless you have some specific performance numbers you can give us I wouldn't be so quick to jump to all of these doom and gloom assumptions.
Although I can agree on one thing. I rather force player to upgrade machine for fetures they might really notive, like Cloth simulation, Fluid simulation, mega-texturing or more advanced self-collision rigid bodies.
we need some tech guru here... to explain how it works....
And those saying it will raise the vertex-counts, that's completely not what's happening. With dx11 (and even dx10) hw you can fetch data however you like, you are not restricted to "per-vertex" stuff. And since ptex operates per-quad, you essentially use not the vertex-shader, but the tessellation per-patch shaders (you don't have to tesselate at all and still can use that shader). That way you can fetch data per-quad, and compute uv coordinates on the fly based on patch paramtrization.
So you never store those "quad UVs", they are on-the-fly data, as the paper mentions you only need to store neighborhood information per-quad to do texture interpolation along the quad seams.
As for baking, all quads... all that is a matter of tools. But it's a typical chicken egg thing, few users of the tech, few tools, few tools, few users...
That said I think it's perfectly fine for technology to be useful without being "standard" for every asset in a game. As some mention they paint in 3d and bake to classic 2d uvs.
rough description of dx10/11 pipeline
http://crazybutcher.luxinia.de/wip/pipeline.png
http://developer.amd.com/resources/documentation-articles/samples-demos/gpu-demos/amd-radeon-hd-7900-series-graphics-real-time-demos/
[ame="http://www.youtube.com/watch?v=zYweEn6DFcU"]AMD Leo Demo: AMD Radeon? HD 7900 Series Real-Time DX11 Graphics - YouTube[/ame]
I am not looking for ways to do the least amount of work possible,or cut out as much work as possible that I can do.I am one of the most hardworking person u have ever come across.
I am interested in techniques that might solve limitations I encounter while working.Tools or plugins that can improve and fasten ones workflow and most importantly,enable one to meet project deadlines with good quality standards.
Once in a while,I ask questions here on certain technologies or techniques that are being developed or used that can solve problems,limitations or make workflow better because I am a one man team.I do all of my work myself and I don't want to even start mentioning the power problems over here.Its really very bad.U can imagine how that can affect what u are trying to accomplish.U live in an environment that permits u 24 hrs power supply throughout the year.
Unfortunately,not all of us are that lucky.
I am no engineer or math wiz, but why does they not remove the mesh and use the textured-polys/tris to replace the mesh.. And then use smaller size texels for high res and bigger for low res, like games. Like instead of connection polys they connect tiffs
And now MARI has Ptex support and is super nice to paint in.
And for concept art, this really speeds up the flow. The only think I dont find is a renderer that supports Ptex and is small enough to be managed by one person, Renderman I heard is big and complex. Would be nice if Keyshot had that support.