Best Of

Artstation Challenge Submission [Completed]

My Submission for the latest Artstation Challenge.

https://www.artstation.com/artwork/qQGGbD

Corweee

3 ·

Re: The Bi-Monthly Environment Art Challenge | September - October (80)

incremental progress today:

PaulJChris

6 ·

Re: The Bi-Monthly Environment Art Challenge | September - October (80)

Ive added the sand, plants and some particles to the scene. Also fixed the line thickness of the line weight on the trim sheet. I think I'll have to fix the black lines on the egg statues and make them blend in more as well now to match. Gotta figure out the mossy areas and the lights that fill up the ground. Never done those kinds of effects. Thinking about maybe doing decals in unity. Or floating geo with an alpha? Kind of the same but also open to suggestions!

https://vimeo.com/758194330

squarebender

5 ·

Re: The Bi-Monthly Environment Art Challenge | September - October (80)

Still chipping away at the scene. Currently doing an texture atlas for items on the desk. Then I want improve the window, trims and cobwebs.

@squarebender looking good! If you choose go with the light hitting the chest, you could alter roughness and spec values in the cavities so the color doesn't blow out as much and to control the highlight.

Fabi_G

6 ·

Re: What Are You Working On? (3D) 2022

Hey Polycount! Here's a vampire army I worked on for the Lord of the Print october release. Here's one of the generals, the rest is on Arstation!

https://www.artstation.com/artwork/8w0w4n

DoctorBloup

4 ·

Re: Rawk - Post any rocks you make here!

Hi! I'm glad to show rock creation technique with UDM

Unified Detail Mapping (UDM) in this particular case is used to obtain large shapes when viewed from a distance.

Since the close up detail is provided in the regular tiled textures, with the UDM map we show great details after baking highpoly from ZBrush.

At Shatterline, we used this method to create large cliffs, rocks, trees, etc.

For the rock and moss tile materials, I used scanned textures from our library with polished in Photoshop.

https://www.artstation.com/artwork/14P6r2

nordic_cliff_flat_GIF_02.gif

passes_render_GIF.gif

romaageev

5 ·

Sketchbook: Kahze

Hey everyone,

I used to go by "Neolight" on these boards and then stopped posting after entering the industry to do being too busy working all the time. I am now returning as "Kahze" which has been my official digital art handle for several years now. I'll continue to be Kahze from here on out, it is the name I have found I am most comfortable with.

That said, allow me to re-introduce myself. I'm a game artist, I've worked in AAA for several years as well as indie. I got my start in the industry at Insomniac Games where I worked on Ratchet & Clank for two and a half years and some other projects we had going on there. I then left Insomniac to start my own studio DreamSail Games and shipped two games on PS4 and Steam. In my spare time I contributed to other indie teams and also tabled artist alley at furry conventions and took allot of commissions.

I am an anthropomorphic focused artist mostly, but I love to make all kinds of game art so long as it fits within the realm of fantasy or sci-fi. I'll kick off this sketchbook with some of my favorites from my portfolio at: https://www.artstation.com/kahze

justin-sanders-skuther-by-kahzeart-dc2d8go-fullview.jpg

justin-sanders-1547970811-kahze-3ae63190c8f08ec6d4cd439fe46d5477190d3b2f-hq.gif

justin-sanders-dc2d3da-1201e06d-223e-49d1-acfd-8310522596e3.jpg

God Speed to you all, and I'll see you around these boards.

Kahze

5 ·

Re: The cost of a texture "draw call"? (Quantity vs Resolution)

Some in depth details here http://on-demand.gputechconf.com/gtc/2016/presentation/s6138-christoph-kubisch-pierre-boudier-gpu-driven-rendering.pdf although I also recommend the "renderhell" article by Simon.

In general the most important advice is to make use of the engine's profiling tools. For a few years GPUs are quite powerful, you can generate drawcalls on the GPU without the need of CPU, you can pull a lot of data as you need it (aka bindless). As was mentioned, we have APIs that were modernized for higher throughput, submission from multiple threads etc.

Therefore engines can make use of a lot of features depending on their target platforms. They may bake/batch data in different ways.

"it depends" is more true than ever.

CrazyButcher

3 ·

Re: The cost of a texture "draw call"? (Quantity vs Resolution)

Shrike said:

- Realtime lighting and shadows multiply your vertice count effectively in engine but is unavoidable
- As one vertice can only have one material, UV, RGB etc, coordinate for each, adding a second UV doubles the vertice count again
- Layering materials on the same mesh should be avoided, split the mesh into the material parts as this again cases tons of unneccessary vertices as a vertice can only have one material, so they are doubled again for the new one
- Vertices up to a certain degree are easily handled by decent GPUs, materials and drawcalls usually are more important to watch out for

As example; If you have one car and the car has one mesh+mat for interior, one mesh+mat for lamps, one mesh+mat for windows, and one mesh frame that uses multiple materials for the details on it, like a chrome trim and whatnot, this is easily 5-10x the vertice and drawcall / shadow caster count and effectively performance drain - than having it all in one mesh and material, even if the actual model is not any different.

Now where I scratch my head the most:

(?) Material transparency is very expensive (in Forward only?)
(?) Drawcall performance is not linear, after a threshold that it becomes the main performance bottleneck as there is a physical limit the CPU can handle well
(?) Textures operations effectively cost performance in a material depending on texture size, but texture amount is not really important until you reach the GPU cap of (16 at UDK times?) - it just is part of your shader performance budget and an operation like others
(?) You can save texture operations in shaders by saving different maps in different RGBA channels, which then is 4x more performant for the operations as 4 invidivual maps?
(??) The texture overhead is depending on the passthrough/bandwidth of your GPU, if that is too slow you will see bigger FPS losses, and as long as your video memory is not full, overall texture size in your game does not really matter, but when its full, its going to be a huge fps sink unless it automatically turns down to the lower mipmap - (Im really confused about the entire texture thing still, size dosnt matter but also it does?)

Hopefully I can deepen your understanding a bit. For the most part you are close to the truth. The items you're 100% correct on I've omitted from the quote.

Regarding realtime lighting and shadows: Realtime shadows do require running vertex processing and draw calls for all of the meshes that the light affects. The way that shadows work is that the renderer draws a depth buffer from the lights' point of view, then when the lighting happens, if the fragment being shaded is further away from the light than it is in the depth buffer, the fragment is in shadow. So whenever you have a light with shadows enabled, it transforms and rasterizes all of the models affected by the light before the lighting happens, but doesn't perform shading as only the depth is needed.

Lights are a bit of a different ballgame and whether or not they require more vertex processing depends on the rendering algorithm. If it's a deferred renderer, the meshes get drawn to a G-buffer, with all the information needed for lighting in a framebuffer that's rendered from the camera's point of view (except for shadow buffers.) So, adding more non-shadowed dynamic lights to a deferred renderer is pretty cheap because you don't have to run vertex processing more than once for all of your lights, and the amount of time it takes to do the lighting depends on the number of pixels that the light takes up on the screen. However, with a deferred renderer, you still must render shadow buffers for any lights that cast a dynamic shadow.

In a forward renderer, dynamic lights are more expensive to render because you have to potentially do vertex processing more than once if the mesh is affected by multiple dynamic lights. You can see how this works in an old-style, multi-pass forward renderer like Doom 3 here. http://fabiensanglard.net/doom3/renderer.php (ctrl+f "Now the details of what happens in the GPU framebuffer:") Note that the results of each light are accumulated in the final frame, and there is no G-buffer. It is possible to do less passes and less vertex processing if you compute the results of multiple lights per pass, and this is more important to do the more vertices that there are. The combination of easy MSAA and higher potential performance makes single-pass forward rendering the natural choice for VR rendering.

So: shadows definitely increase your effective vertex count, but lights don't necessarily. (It depends on the renderer.)

Regarding second UV sets doubling vertex count again: This simply isn't true. In the case of a second UV set, the renderer will have an additional attribute per vertex. So the mesh will take up a little more memory, but it won't take any longer to rasterize.

That's true as long as the UV seams are the same for the first and second UV set. If the seams are the same, the duplication of the vertices along the seam has already happened due to the first UV set. If the second UV set has seams that aren't a split normal or a seam already in the other vertex attributes, it will cause additional vertex duplication along those seams. But it is pretty rare that such a scenario happens.

Regarding material layering: Absent of tricky techniques like UE4's hierarchical LOD or texture atlasing, having multiple material slots causes that number of draw calls to happen. Material layering in a shader like Epic does it saves draw calls, but increases the complexity of the shader somewhat. Layering materials in the texture authoring process is free in shaders/draw calls, but makes you a slave to texel density and can take up more texture memory to get the same amount of detail. Each approach has its place, but on mobile you probably want to use the Photoshop approach to layering materials.

Regarding vertex count vs. draw call/materials: It depends on the scene and the hardware. A problem that you're more likely to run into is a rasterization bottleneck from really long, really skinny triangles and really small triangles. Importing your model into UE4 and using the quad overdraw view mode can help you diagnose areas of the mesh that are likely to cause a problem. This is the main performance problem that you can run into with Alien: Isolation style, extremely beveled models. For vertex count and draw call count, as long as you keep things reasonable you should be fine. On any renderer you will get reduced performance from having thousands of small draw calls towards the end of the frame with only a few hundred vertices per mesh. If you have a scene with lots of small accessories and it's causing performance problems, try to put them in a texture atlas and you should see things get better. UE4 HLOD can do this automatically for static meshes.

Regarding the car example: this number of draw calls may actually be completely fine on a desktop game. Car rendering is a bit of a special case because the extremely glossy surface of the exterior makes normal map compression artifacts unacceptable. Modeling such an exterior requires a lot of polygons and probably transferring normals from another mesh. Using vertices for normal manipulation works better, because the normals get interpolated perfectly smoothly between the vertices.

The windows must also be their own material unless it's acceptable for them to be extremely tinted, because if the windows have transparency enabled and they are in the same material as everything else, everything else will also have transparency enabled, which will decrease performance a lot and potentially cause triangle ordering jank. So, if you're rendering a car, you are probably looking at a few draw calls, but that's OK because they are getting put to good use.

Now for the head scratchers!

Material transparency: Yes, it is expensive, especially if you're trying for some sort of dynamic triangle ordering for hair, or some order-independent technique. Deferred renderers written by people who are trying to stay sane render transparency in a separate, forward pass. There are all sorts of ways to render transparency, and they're all expensive. However, if you need transparency for your scene, you should use it. Just don't go too crazy. If you're rendering a skyscraper from the outside, you might be able to get away with making the windows shiny.

Draw call performance: It depends on the graphics API in use, and in some cases how well the API is being used. Even in an API where individual draw calls are cheaper, if you have tens of thousands of draw calls and 80% of them have only a few triangles, you'll end up with a "death by a thousand cuts" situation where the GPU doesn't perform as well as it could. Vulkan and DX12 can handle more draw calls than DX11 and OpenGL, if the renderer was written in the best way for each API. In general, if the number of draw calls is less than "way too many" you will probably be fine on the GPU side. On the CPU side, additional draw calls require the CPU to set up more commands for the command lists for the GPU, and that takes time, but you can use quite a lot of them with the new APIs. Again: This isn't a license to go crazy with them!

Draw calls and texture slots have basically nothing to do with each other, but draw calls and material slots (and, for that matter, individual meshes using different materials from each other) are usually 1:1.

On mobile, it's still important to use less draw calls, as it means less work for the CPU and less power consumption.

Texture performance: You're more or less correct. The main performance reason to use less textures is simply that textures take up a lot of video memory. There are other costs-setting up the texture samplers, dealing with image layouts, and so on-but memory is the main one.

Texture performance 2: The main reason to pack textures into channels is to save video memory. A DXT1 texture, 1024x1024 with red, green and blue channels takes about 0.5 MB of RAM, and a DXT5 texture, 1024x1024 with red, green, blue and alpha takes about 1 MB of RAM. So if you have four masks that you need, not only will you be taking up 3 more texture slots that you could use for something else, you will take up twice the video memory compared to putting each one in a grayscale DXT1 compressed texture. Of course, if you have three masks and you can pack them into a texture with no alpha channel, that will save even more video memory. However, the DXT5 packed mask compresses the alpha channel independently, so if one mask has a lot of high frequency detail it should go in the alpha channel to avoid cross-talk with the other channels. The mask with the second most detail should go in the green channel, as that gets one more bit in a DXT5 texture than the other two color channels.

However, doing this won't appreciably increase shader performance.

Texture performance 3: What you're talking about happens when you've used more VRAM than you're supposed to. If the graphics card can't fit all of the needed textures into memory, it will have to go out, over the PCI-E bus, to main memory to be able to fill in that texture. This is more expensive than just about anything and of course you should avoid it. As long as you use texture compression, avoid super high resolution textures, and keep the number of textures in your scene reasonable, you're unlikely to run into problems with this on a desktop GPU. This is the problem that id tech's megatextures are meant to solve.

I hope this was helpful to you. Many Bothan spies died to bring you this information.

JedTheKrampus

4 ·

Re: Dream Fusion 3D models. Is the end close for 3D artists?

While it is true that it is indeed "just another tool", I feel like there are massive blind spots in people's appreciation of the consequences of all of this.

Sure, the output of this or that AI algorithm isn't perfect or production ready, and artists are not going to lose jobs overnight because of it. And of course it's neat to have access to such a literal "make art" button - especially for AI-bros who just love the fuzzy feeling of "creating" something by typing in a prompt.

But one of the very real consequences of all this is that we are already at a time where the output of such prompts is directly usable in moodboards and thumbnailing/brainstorming. This is of course a lot of fun to play with (and I would encourage everyone to do so, as this stuff really is fascinating), but that also means that panels like this (100% AI generated) are now a thing :

Now *of course* one could prepare a similar collage with a few hours of googling, so in and of itself that's nothing new and both processes are similarly derivative.

But that also means that inevitably, there will be cases where some artists (the human ones) are going to be tasked to work from something that comes directly from an AI image generation tool, as opposed to coming from a human designer/curator. AI evangelists will of course say that it doesn't matter, that it's just a tool, and that speeding up a process is never a bad thing ; but there will absolutely be some people who will straight up refuse to be part of a process in which the thing that is handed down to them didn't come from the experience, knowledge and craftmanship of a designer (even if they never met that person IRL) but just a text prompt with the always useful "trending on Artstation" bit thrown in for good measure.

This rejection will not be because of the results being bad, but because it simply is less interesting since it means being unable to have any conversions about where an idea came from, what the influences of the art director are, and so on.

So to go back to the example of mocap and animation : sure, mocap didn't kill traditional animation. But will an animator specialized in manual animation (or even just mocap cleanup work) which up until now was always based on human capture, be just as willing to do the same work if based fully on a AI-generated sources ?

I am 100% sure that it won't take long for some studios to experience this first-hand and that we'll see some studios and companies positioning themselves as not using AI in their creation process, regardless of it being a useful tool or not. Because even though no one is owed a job, there is still a very real incentive in making sure that a team is working well together and solving problems and design challenges as a tight unit. Of course the deciding factor will be whether or not it will be sustainable to do so.

I am also very interested to see the reaction of the general public a year or so down the line, when we'll start hearing AI-generated music at the mall, or when we'll start seeing tons of products being advertised as "designed by AI". Some will love it because it's new and interesting, some will consume without giving it any second thought, and some will undoubtedly hate it.

pior

5 ·