Alternative solutions, possibly next gen solutions...

Obscura

Hey guys, I just like to hear your opinion, about the nowadays spreading solutions/workflows, such as advanced bevels (face weighted v normals), advanced decals, ptex, and such. I have very good experiences with the first 2 things, but I'd like to see what do you think of them. Actually looking for evidences, opinions, experiences, and more possibilities.

I've talked with a few of the actual users of such techniques, and saw some supporters (cause of understandable reasons), but I'd like to see how they apply in the industry, and what people see/think from them.



I'm still not perfect in the topics, and still looking for the possibilities/downsides.

I'm interested to hear about any experience and opinion about any alternative or next gen stuff. Even experiences with only PC stuff or DX12 stuff.

Links to my researches:

Normals:
http://www.polycount.com/forum/showthread.php?t=154664

Decals:
http://www.polycount.com/forum/showthread.php?t=155894

Ptex:
https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Borderless%20Ptex.pdf
Theoretically in every Disney animation work since 2007.

DX12:

"Witch chapter 0 [cry]" is an awesome showcase, and I believe we can see it in some of the next gen games gameplay trailers. The UE4 elemental demo under dx12 was pretty disappointing, but actually thats the artists fault...

Voxels:
They can be used, was used, and they are used for so much things.
[ame="https://www.youtube.com/watch?v=DbMpqqCCrFQ"]Euclideon engine[/ame]
[ame="https://www.youtube.com/watch?v=_E1oVl2d01Q"]Voxel based global illumination[/ame]

Voxel basedd volumetric fog
Voxels from the old times
There are many potentials in them.

DireWolf

I can't see your signature.

Obscura

I think its because you are logged in. Sorry, I updated the post with the links.

Eric Chadwick

This is good stuff! I love seeing these kinds of threads, and the inquisitive minds behind them.

It seems you are interested in technical art. This is exactly how many tech artists get started, by researching topics, trying to figure out how they work, and trying to improve on them with their own work. I'm thinking of Haiddasalami, just to pick one example.

This is also useful for any 3d artists who also like technical subjects, but are probably not intending to become actual technical artists. Like myself. Another example, Simon Trümpler and his Game Art Tricks.

Keep exploring, keep experimenting, and keep sharing your results.

Looking at your "Old portfolio", I see a couple things that could really help. First, don't call it "old" which sounds like an apology. If you don't like it, don't share it. But I think it's good to have. 2nd, make a proper website for it, just one page is enough, with contact info, a little bit of text for each image, etc. 3rd, add identifying info on each image, so the images always link back to you, even if someone saves it off the web, or puts it on Pinterest, a small watermark will help people get back to you.
Your Portfolio Repels Jobs
http://wiki.polycount.com/wiki/Portfolio

Obscura

Yeah, Simon's thread is epic. I learned a lot from it. Its also a great example for alternative solutions.

As for the old portfolio thing, actually I have no problem with them, just the most of them are actually old, and unfortunately I haven't had time to update. Also, I know there are issues with the current presentation. I'm planning to make a completely new portfolio soon with mostly technical art in it. I just need more art to work with first. Thanks for the advices!

Eric Chadwick

Everyone's portfolios are old. Everyone is planning to add more recent art. Calling yours "old" is a bad idea, just as people adding work labeled WIP is bad. It says "I'm sorry my work sucks". Really, this is exactly how potential employers judge it. My point is... either own it completely and un-apologetically, or don't post it at all. The quickest solution is to simply change your signature text to Portfolio.

Obscura

Haha you are right, I did that. Thanks! Any other opinion, experience or example related to the original topic? I'll look around on the wiki for more, and add them here too.

Obscura

Anyone know any info about the ptex thing? I saw the tech demo by nvidia, and it is showing the logic, but I'm not really understanding how people could work with it. Also, it would require many texture samplers? Or many drawcalls? Will this be used in games in the near future? I saw many amazing tech by nvidia, but unfortunately the most of them never gets into games.

repete

I really thought Ptex was going to be a biggie in the gaming industry but it sadly never happened and then I got my hopes up for UDIM UV mapping, both options work in mudbox and we have UDIM in modo. Useless in all game engines as they are not supported.

I watched this about a year ago:

[ame]https://www.youtube.com/watch?v=ElVbyLyD_ts[/ame]

Interesting insight :poly121:

We do have PBR though *shrug*

Obscura

Yeah its too bad that they are not supported yet. I don't understand why they are still not. It has benefits. Thanks for the video!

I didn't mentioned PBR because it is very usual now, and the most of the artists know it. But it is an important part of this and the next generations for sure.

Joost

Video to go with the presentation: http://www.gdcvault.com/play/1017757/Eliminating-Texture-Waste-Borderless-Realtime

I doubt we're going to see widespread use of this any time soon but it does seam very interesting

Eric Chadwick

The three biggest problems I see with Ptex for games use...

1) It increases the vertex count quite drastically (this will become less an issue for PC games, but is currently still a problem, and it certainly will be a limit for mobile, and for web platforms due to download times).

2) It requires 3d paint. You can't paint on a Ptex texture in 2D (ala Photoshop). Traditionbal UV shines here.

3) If you're working with lower-res textures, you want your straight lines to be straight in UV space, to minimize artifacts.

Obscura

Yeah, I thought you can't work with it with the traditional methods. As I understand you it gives you those straight uvs by default, or I misunderstand the whitepaper?

Joost

I don't claim to understand it fully myself but:

CrazyButcher wrote: »

ptex doesn't add to vertex counts as you encode things on per primitive level (per face/quad) which isn't necessarily better and means you have to use additional shader stages.

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.

http://www.polycount.com/forum/showthread.php?t=123319

Obscura

Yeah, I was also just checking that thread. To me it looks like it can work, but there are many questions. As the others saying in the UVmap thread... Like how tangents would work, how to use with normalmaps etc.

Eric Chadwick

It seems to give straight lines in the texture only if your lines happen to lie along the same direction as your quads, not often so with characters for example.

Obscura

Ptex also wouldn't give you even pixel density if you don't use evenly sized quads right?

Eric Chadwick

No I meant the topology is often not perfectly lined up with where I would want straight lines in my low-res texture. When every pixel counts, slightly-angled 2D lines are blurrier than perfectly straight 2D lines.

Obscura

Oh I see. Well, I think its still an interesting approach, and it could have place even in real time rendering. We will see where this goes (if it goes at all).

gsokol

About the custom edge normals...

I tried doing that a little while ago but I got fed up with how often Max would reset them to the default angle if I were to use modifiers, collapse the stack, etc and decided it was really more work than it was worth to set them up. Instead of modifying the edges I just stick a containing loop right next to the edges of the bevel to get the same effect. Of course it adds a few more verts, but it saves me the headache.

Obscura

You are right, Max isn't properly prepared for this yet. I add them only at the end of the process because of this.Then it isn't a headache. With a script, its really just a few clicks by the way. Its similar to why you block a model out first, and support and detail it only later in subvid modeling. It needs proper workflow and then it works. I used supportloops (almost same as what you say, just without a bevel, and my drone made in the exact same way as what you are describing.) before I got more experience with custom normals.

SimonT

Just wanted to say "thanks" for pointing to my blog And this thread seems to collect really interesting information. Regarding StarCitizen: The CryEngine Doc says a bit about Decals: http://docs.cryengine.com/display/SDKDOC2/Decals

In general StarCitizen and also Elite:Dangerous have a really interesting way to build assets. Both heavily using decals and it looks really good

Obscura

Glad to see you found it interesting Simon. Your thread helped me a lot with understanding possibilities of methods in games. Its a fantastic collection. Anyways, I talked to Joost earlier, and he said they don't use decals in Elite (At least in the way as they are used in Star Citizen and Alien: Isolation). But both use a tricky way for having perfect surface shading with Vnormals or supportloops. I think the decal technique combined with the smoothing technique has so much possibilities. It can completely replace the traditional methods (not every time) and there are many benefits in using them. The 2 most important is that the asset creation can be faster and easier (no need of full highpoly), and you can get much better resolution than with the traditional method.

Obscura

Looks like voxels will appear in Max too .
http://www.polycount.com/forum/showthread.php?t=156222

Blond

Eric Chadwick wrote: »

The three biggest problems I see with Ptex for games use...

1) It increases the vertex count quite drastically (this will become less an issue for PC games, but is currently still a problem, and it certainly will be a limit for mobile, and for web platforms due to download times).

2) It requires 3d paint. You can't paint on a Ptex texture in 2D (ala Photoshop). Traditionbal UV shines here.

3) If you're working with lower-res textures, you want your straight lines to be straight in UV space, to minimize artifacts.

<



Neither are a problem. You could most likely do UV first, paint on the UV'S then bake that data into 3d painting (ptex)...I think

Avvi

What about vector displacement? Was it used in any real game?

[ame]https://www.youtube.com/watch?v=SYU3YU3d7GI[/ame]
[ame]https://www.youtube.com/watch?v=Iuv4TY2-gdA[/ame]

Obscura

It is called multi-direction displacement in Blender. This is the only thing I know about it other than what you showed . I think this should need 4 channels (r,g,b,a) to store the direction and the amount. A positive side can be against simple displacement is that you need less detailed basemesh with this. The ear or even the sphere example couldn't be done with simple displacement, because the verticles are not only displaced along local Z, but they are going into different directions based on the map(?). I'm not sure if it worth anyways, because you can get more optimized mesh with using a more detailed lowpoly. This is my opinion about the whole realtime displacement thing, but it depends on the case for sure. I just mean it is very wasteful on hard surfaces.

Avvi

I see. So that's why they needed to prepare a specific, dense low-poly "plane" for the ear. Probably hard to use.
Thanks for the Blender info! People seem to had luck with this even in the prehistoric 2.4x version (link)

Obscura

Yeah it seems its hard to use it, personally I can't imagine how to make a map for it. I was thinking about it a bit, and the UDK example must be done with vertex colors because world position offset eats only that, vectors, and maths.