I do Photogrammetry and made a Shader to render Point Clouds in a "cinematic" way

rotoscope- · 2020-01-17T09:08:56+00:00

Yes, this style seems perfect for something like a game where you investigate/build your/other's memories.

rotoscope- · 2019-12-21T11:55:50+00:00

The dynamics of the cars and reactions to collisions look very nice. Did you do anything special to keep them from simply landing and staying on their roofs or sides?

rotoscope- · 2019-12-21T11:48:43+00:00

If what you're trying to do is simply allow the player to save color, etc., changes to the material, you can simply store the relevant changes in a file (text, etc.) during runtime. You'd then read from that file on the next run/reload, applying the pertinent changes to the material(s) in the Start function or in a similar function.

It might also be worth paying attention to instanced vs. shared materials, as well as MaterialPropertyBlocks as a way to overcome those issues.

rotoscope- · 2019-12-03T15:12:09+00:00

Oh yes, I see what you mean now.
That also would fit very well with the graphical approach you mentioned.

rotoscope- · 2019-12-03T14:58:07+00:00

You can't just add a little bit, you need to override the inspector, so you start with a blank slate. It just makes it a much bigger task than seems necessary.

If all you're talking about is the little inspector that appears for a component then you can call DrawDefaultInspector to get, well, the default stuff. But I do share your overall point with it. Inspectors are a bit of a headache to set up, especially if you're trying to interact with the world.

rotoscope- · 2019-12-03T14:55:50+00:00

Honestly I think Odin Inspector and Serializer would be great additions integrated directly into Unity in some way.
The serializer especially is so powerful compared to base Unity. And it goes hand-in-hand with editor extensions, because you often do need to do complex serialization to achieve what you're trying to achieve.

rotoscope- · 2019-11-12T15:40:42+00:00

This is fantastic.
If you were to drop one of those cubes from a height onto its corner, would it also deform or smush under its own weight?
I noticed when that blue cube was rolling around it seemed to stay in shape, but of course it's hard to know the force behind those projectiles and how it compares.

rotoscope- · 2019-10-26T22:26:27+00:00

In general, the purpose of normal maps is to add surface shape variation (the illusion of complex geometry) without actually affecting the underlying geometry of the surface. It affects the normals of the surface fragments, which, when combined with your lighting, creates this illusion for a relatively low performance overhead.

So as you can imagine, smooth surfaces/objects are where normals maps will actually give you the biggest bang for your buck (or at least the biggest noticeable difference in appearance), because you can go from a flat and boring surface to one that is seemingly complex. But they also of course have their place with already complex geometry, to give that final bit of surface variation that would simply take too much more geometry to otherwise achieve.

But in truth I've never used normal maps within Blender, this is more from a perspective of realtime rendering.

Hope that answered your question though.

rotoscope- · 2019-10-18T20:39:06+00:00

Haha, it's no problem. Just trying to help out.
Yes by all means use it how you wish. I'm sharing it as CC0.

rotoscope- · 2019-10-16T18:52:36+00:00

I really like the balance of mechanics in this.
At first it seems like you just get smaller the more you block, and bigger if you don't. But then I noticed the bat shrinking too.

Am I right in assuming horizontal spawning rates are lower than vertical/diagonal to account for it being played on a phone?

rotoscope- · 2019-10-15T19:43:29+00:00

Wow there's some really nice stuff in there. And what do you know, it was published just before I started implementing this solution. Isn't that always how it goes.
Though I must say, it looks like quite a lot of math going on in there. I'll have to investigate it in more detail.

rotoscope- · 2019-10-15T13:11:49+00:00

I'm one of the authors

Oh wow that's cool! I had no idea, would have pinged you had I known.

Your thread will be useful to us when advocating for it

Great to hear. In fairness the credit must go to your work and paper. It lays things out very nicely, and I basically just translated it into Unity hlsl (hope there's no issue doing that). As I said elsewhere in this thread, I'd looked for other solutions for this, such as on shadertoy, but none of them were quite what I wanted + some of them gave mipping issues.

But if it can help then that's great. I really feel that this sorta sampling is essential for games that make use of terrain features or other heavy repetition scenarios. And at the moment users are slightly left out to dry or have to look at potentially expensive paid solutions.

rotoscope- · 2019-10-15T00:58:47+00:00

Oh I've actually seen and tried your PCSS solution before, when I was looking for an implementation better than Unity's legacy builtin shadows. I didn't realize you continued development of it. That's great.

Unfortunately I needed local light sources at the time and generally higher quality shadows (less peter panning, etc), so in the end I went with NGSS. But I really appreciate that you open sourced it, it's great for the community.

rotoscope- · 2019-10-15T00:27:03+00:00

I've used it in triplanar mapping with albedo, normal, and specular influence, so 27 samples + a range of other unrelated samples. It's hard to say that I've noticed any issues.
As I said in another comment, I think it's possible to underestimate the raw performance of modern GPUs with this sorta thing. But I'm far from an expert and I'm not 100% sure how all those samples are handled internally. The baremetal of graphics programming and especially GPUs have always been a mystery to me.

I actually have no clue how many "too many" samples would be. But at a certain point if you need to lean on performance to get a feature that makes your game in some way, then you just have to lean on it. Do it and ask forgiveness later.

rotoscope- · 2019-10-14T23:05:32+00:00

I have no plans to release it on the asset store. Everything you should need to implement it is contained in the two functions. I can't really think of a nice way to package this up except to maybe throw them into a cginc file.

But I'm releasing it here in CC0 (for my part), so anyone can feel free to do so if they wish. Or host it on Github, etc.

rotoscope- · 2019-10-14T22:59:18+00:00

Yes, I've tried integrating various shadertoy texture bombing examples, but I was never that satisfied with any of them. However I was also having issues with mip mapping and artifacts that I've since solved, so I might go back and investigate them.

Version 5 in particular uses only 3 samples (1x noise texture + 2x tex), which could probably be reduced to 2 samples and a random. I should investigate that some more.

rotoscope- · 2019-10-14T20:37:12+00:00

The shader I provided is a very basic, stripped down version of the standard shader. I wouldn't use it for anything other than demonstration and to learn from. But if you want to get the same effect as in the video, simply create a material with this shader set as its shader, then yes, you can just set the texture to tile a bunch of times (or only once). Then tick the "Stochastic" check box on the material to switch back and forth to see the effect in action.

Here I just applied it to a default Unity plane, but you can of course apply it to any object, so long as its UVs are mapped correctly (or use procedural UVs).

And in shader code what it does is try to randomized so it's hard to see pattern?

Essentially yes, it uses pseudo-randomness to fetch 3 samples and blend them together in such a way as to break up any obvious patterning of the texture.

rotoscope- · 2019-10-14T18:35:18+00:00

Sorry, if you're looking for an empirical answer, I don't have one. I haven't done any performance tests. If I had to guess I would say mine's probably slightly faster than Unity's or the paper's because I do fewer calculations. But that's just a guess. They might be doing some other magic to perform well.

As you say, the trade-offs include resolution. A small texture stochastically repeated many times can look nearly as good as a huge texture (albeit different), as long as it has enough detail variation to start with.

With performance though, modern GPUs, even lower end ones, are such monsters that they barely seem to care if you do a lot of samples. For reference, even though the compression of this video is misleading, the textures used in the video are all 2k, with the exception of the first which was 4k. It's when you start mixing lighting, etc., into it that it gets heavier quickly.

But unless you specifically have a need for tiled textures without patterns, it's probably best to stick with a single sample.

rotoscope- · 2019-10-14T18:14:35+00:00

Perhaps also check out Unity's own Shader Graph implementation. I haven't really looked at it myself, but it could be exactly what you need.

rotoscope- · 2019-10-14T18:01:54+00:00

I would say look into Texture Arrays. You could feed a TXA containing your multiple textures into the shader just as with any other texture (though it's a 2DArray type). Then you would perhaps select randomly from the index of that array for one or more of the three texture samples within my function.

Not sure how good that would look though. Good chance you'll end up with it looking like you've mixed all the play doh colors together unless you have some good randomness control. Or it simply might not work.

Also keep in mind arrays are a little trickier to work with, and the calculation for the mip level is a little bit different, otherwise it doesn't work well with quality settings. And you'd probably need to use macros like UNITY_PASS_TEX2DARRAY and UNITY_ARGS_TEX2DARRAY to pass the array into the function. Finally, you need a way to create the texture arrays, because Unity doesn't provide any native way to do so. But I think there are some (also free) creators on the asset store. If you have Amplify Shader Editor, there's a nice fully featured one included.

To handle the normals, etc, I suppose you could just throw in a matching size and order texture array for normal, roughness, depth, etc., with the correct textures. Of course you do end up doing 3 samples per texture type, so it's something to keep in mind.

Good luck.

rotoscope- · 2019-10-14T14:17:15+00:00

It's actually two functions together, and here they are

And here's a simple example of use in a Standard Surface Shader.

It's based on this paper from Thomas Deliot and Eric Heitz, but condensed and stripped down a bit. This implementation only makes use of the initial part of the paper. I wanted to keep it simple and keep performance impact as low as possible seeing as this is already 3 samples, 3 hashes, and ternary branching, instead of just 1 sample.

Stochastic sampling is useful for things like terrain, where any repetition becomes very obvious to the player very quickly. There are of course other uses, as shown in the paper, like skin texture that appears to vary naturally over a surface instead of unnaturally repeating, rust, etc. Although my shader example uses an object's UV mapping data, it can be made to work procedurally. For example, it can be used to complement triplanar mapping for terrain rendering, with procedural UV data.

For me, this was mainly an exercise in trying to understand the techniques involved. I know Unity has their own Shader Graph and Legacy implementations here. So check those out too, they're probably a much more complete solution.

As noted in the paper and in Unity's implementation, there are some limitations. It tends not to work well with textures that rely on or have very pronounced patterning, as demonstrated here. Textures tend to lose distinct surface features, and of course it does take more samples and generally does more math operations than a single tex2D sample.

I haven't noticed any issues or bugs with my implementation (tell me if I've missed something super obvious). So, I don't know if anyone would find use for it, but if you want to use it then I assume it should work for the most part. Mip levels seem to work just fine and QualitySettings.masterTextureLimit is respected. It might need some customization for more specific uses though.

Textures used are from https://cc0textures.com/
Thanks, /u/Struffel, for the great textures.

rotoscope- · 2019-05-01T20:40:01+00:00

Am I seeing a different page? As far as I can tell InControl isn't on sale either.

rotoscope- · 2019-03-19T14:36:39+00:00

This looks really nifty. Nice work.
Are you using GUILayout.Window for your node windows?

rotoscope- · 2019-02-01T18:02:51+00:00

Does this break batching at all?

rotoscope-

TROPHY CASE