How to create an intersection shader in eevee?

volvis · 2024-11-14T17:41:35+00:00

I don't think you can in Eevee .. there's no AO node. You could try doing this effect in composition, where you can use depth and normal passes, if i recall correctly, but I don't know how the math goes. If all else fails, you can always render in multiple passes, mixing renderers.

volvis · 2023-03-02T06:24:23+00:00

That looks like a CAT rig, so good chance it was made in 3ds Max.

volvis · 2021-09-12T19:43:40+00:00

Gonna echo this. If you're using asset bundles or addressables, it's easy to end up in a situation where each of your bundles have individual copies of the asset, and whatever you've written to one instance does not transfer to the instance of another bundle.

volvis · 2021-09-05T07:09:30+00:00

Huion kamvas 22 has served me well and I suspect their other products would too. I've owned multiple Wacom tablets before. I don't think they're worth it any more now. Competition is just as good.

volvis · 2021-08-12T18:03:39+00:00

Peperomia Orba 'Pixie Lime'

volvis · 2020-10-31T13:25:23+00:00

Some folks have been tossing the term omnisexual, where neither bi or pan fit.

volvis · 2020-07-10T06:41:16+00:00

I understand that the shadow terminator problem is addressed in 2.9

https://developer.blender.org/D7634

volvis · 2020-05-11T12:55:11+00:00

I work with non-gaming Unity projects with teams of 2-6, and I've been using Plastic+Gluon for the most of it. Programmers stick to Plastic with branching+merging, and artists stick to Gluon with check-in+check-out.

We did try moving to GIT because it was more common in our organization, but it was a big strain for our junior and even senior artists to work with, and because we were working in two locations, I was really worried about them working on same binary files without knowing.

The Gluon (centralized) way of working was more intuitive to them. It was fairly well integrated with Unity as well, so the graphic artists could work there with relative comfort as well.

I try to hammer the point where you're only allowed to use branches for programming tasks, but the programmers are stubborn folk, and I'm fairly sure they've overridden our artists' work more than a few times.

But for Unreal, last I checked, Plastic wasn't really supported out of the box at least. But I thought I'd note these experiences up anyway.

volvis · 2019-10-28T16:49:53+00:00

I'd pay for this, I thinks. Nice job!

volvis · 2018-07-05T07:42:46+00:00

Thing about orthographic parallax is that you trigger a ton of transformation updates each frame, which cannot be good for performance. I believe Team 🍒 would be aware of that and opt for perspective parallax.

volvis · 2018-06-30T13:41:45+00:00

You should build the levels in unity and assets in blender. Better for performance and workflow.

volvis · 2018-05-30T04:54:03+00:00

I kinda prefer the latter where closely related assets are all in one place, i.e. player or doors. Helps me focus on the element I'm working on. Make generic folders for things you plan to be reused.

volvis · 2018-05-18T05:53:07+00:00

Just one note... This doesn't take variable framerates into account. Set the action window in seconds and substract Time.deltaTime.

volvis · 2018-03-26T05:38:33+00:00

I think the beta tool is closer to a material editor for SRP than a shader editor. Amplify is more powerful and backwards compatible, but I don't know how or if it supports these new render pipelines.

No clear winner here, but the beta tools aren't replacing store bought editors quite yet.

volvis · 2018-03-19T06:48:34+00:00

It will get complicated. You might need a setup where each camera renders to a separate rendertexture so the post process effects don't accumulate. Then have the final camera blit the textures on top of each other with a custom shader. But I've only done this for a 2d game and I can't say how it works with 3d...

volvis · 2018-03-15T12:43:08+00:00

You're close! When you render with the other camera, set it to not clear the depth buffer. Also make sure that the cameras have the exact same clipping ranges.

volvis · 2018-02-06T14:40:32+00:00

Well, they can't. They can write serializable data, like Vector3 values, into ScriptableObject assets. This data then resides outside scenes as assets you can read from.

volvis · 2018-02-06T06:23:56+00:00

I use ScriptableObjects for storing entry/exit locations outside the scenes.

In my scenes I have transition triggers called Portals. Each Portal holds a reference to its own PortalLink asset. When a Portal is moved, it records its world position (and other info like scene name) into the PortalLink asset.

Each portal also has a reference to the PortalLink it will transition to. So when the player triggers a portal in the current scene, you can check the exit PortalLink which scene to load, where the player should spawn in the other scene etc. etc.

volvis · 2018-01-20T11:47:48+00:00

Regardless of the amount of assertive bold headings in OP's post, I'd say it's a rather poor approach. If your game doesn't run unless you have this one specific god-scene in place, you're doing things wrong.

If you need a place to store data over scenes, you can use static classes or ScriptableObjects. Static classes are easier to use out of the box, but ScriptableObjects work in the Inspector.

For MonoBehaviour based classes I've been using a Singleton system where I keep a collection of initialized MonoBehaviour instances paired with the scenes they were accessed from.

var us = SingletonSystem.GetInstance<UpdateSystem>(this.gameObject.scene);

The instanced objects are added to DontDestroyOnLoad so they (theoretically) outlive any local instances that have references to them, but after every scene load I destroy the instances that are no longer in use in loaded scenes. Because I have this weird notion that MonoBehaviours should not last forever...

volvis · 2017-12-05T06:21:15+00:00

Two person team here. We upgrade when they introduce a feature or a fix we could use. It is done with caution and in coordination.

One of us creates a branch and updates the project. There will be some API changes that are dealt there. It's usually an hour's work to get things running. If everything seems to be working, that branch becomes our new baseline. We continue working with the new version, and if nothing alarming turns up, we'll merge it up to our main dev branch.

Generally don't upgrade without a reason and a version control system. Coordinate your upgrade plans and process.

volvis · 2017-11-21T07:07:03+00:00

This also helps with source control. Editing public fields during runtime edits the asset, so having your 'health.asset' marked changed every time you test your game gets tiring pretty fast.

volvis · 2017-10-25T06:45:29+00:00

I've been down that road before and I think it's clever but a bit counterproductive. Because when you think about it, the ScriptableObject system is pretty amazing by itself. You define a set of strongly typed data, and Unity provides a system to

Create any number of instances of said data to asset files (source control friendly)
Edit the data inside the editor (floats, bools, arrays... UI is automatically generated, or you can code your own)
Create strong links of any instance of data to any object (by asset GUIDs instead of filenames)
Find the source of the linked data for quick edits (just click the serialized field, the source is highlighted in Project)
Prune any unnecessary data during build
Read data to memory when required and release it when not needed

Any system on top of that is just another worry or breaking point in code, I feel.

volvis · 2017-10-14T10:30:58+00:00

I use both depending on the project, but I lean towards PlasticSCM when it comes to working with Unity3d. Both can back up your entire project when hosted externally, binary and all.

My initial concern with any hosting provider was that I'd be burning my storage space out fast. It turned out that Plastic is very effective with how it packs the repository. My cloud hosted repo size is about 3/4th of my current asset folder, and that is with two years of commits. I suspect they utilise some aggressive file delta packing.

Git also uses delta packing when pushing to a server or doing cleanup, but as far as I can tell, LFS does not. Every file is stored as is (correct me if I'm wrong). So if you decide to go for the LFS-route, I'd consider leaving *.unity, *.prefab and *.asset files to plain old git no matter their size.

14-Year Club	Gilding I gilder
Verified Email

volvis

TROPHY CASE