So, Nanite

The assets in those demos are a bit overkill, IMO (which is expected from a demo). I expect actual UE5 games to not go that far. I mean, this is ridiculous:

 

Interesting

 

Only if when it's in a scene comparable to what we do in game

 

Depends. I wonder whether a whole fence from post to post is a single mesh which thus inflates the memory or at least SSD space needed, or whether they managed to build that from repeating few very small components.
In the later case, there'd be literally no downside to having that in game and it's even something accessible to indies. Therefore I'd say there's nothing ridiculous about it. Instead it's a remarkable element for a detail oriented player and something that they will share on social media thus making your game more popular xP
Of course, gameplay first, graphics second, crazy details third, but such a cherry on top can still make the difference if the other two are covered.
In AAA titles of the near future I'd expect such things.

 

Who knows. Since Houdini was involved in the creation of Matrix demo, some of procedural objects had to come into UE pre-baked (since it is how Houdini integration works). But which ones? Only the analysis of the demo source files can prove if the fence is an unique object or scripted in-engine

 

Since I'm not at all familiar with Houdini is this saying that may no longer be the case?

https://www.sidefx.com/forum/topic/67922/

 

That looks like it's more implying that the baking will happen in engine, allowing modification before the baking process.

 

I think that baking in this context refers to converting Houdini asset into Unreal native mesh format. Before, you needed to do it manually and specify the mesh type, now it happens automatically before compiling a project. In both cases, any modification done to Houdini asset requires Houdini editor running on the background. So the baking needs to happen sooner or later, and those props wont be generated on runtime/editable in game, as opposed to procedural tools you'd code yourself. I may be wrong though.

 

A couple of thoughts there.

The first one is that when working with architects I've been asked to do exactly this before. So it directly addresses a specific use case for one of their target audiences, even if that audience isn't game developers.

My second thought is that, no, I don't think it's actually overkill after about a minute. My first instinct was to think that it's overkill, because I know that with a traditional approach a fence like that can be managed with a handful of triangles and some textures. But in a modern game "some textures" is at least albedo, normal, and roughness map, all in high enough resolution to not get jaggy edges on those thin wires... and 90% of those textures is actually the empty gaps between the wires.

With this new approach the data can be entirely concentrated around the wires themselves, likely allowing a higher fidelity effect to be achieved with much less overall data.

And if you look closely the vert count isn't that crazy. Certainly the vertex count is a small fraction of what the texel count would be with the traditional approach, and while it's still textured, the textures can now also be a fraction of the traditional size, and possibly fewer as well.

 

This fence doesnt look overkill for me either way. With texture + transparency, you only need tiling (trim sheet) to achieve the effect without needing absurd resolution. With mesh, making a 2d array of sections using script will also be a trivial task. One of the few "procedural" things I could reproduce haha

 

Mh, no. When you look in an angle at a fence that's made with texture and transparency, it would look waaay different. Flatter.

 

I agree that one from the demo is a mesh. I was just speculating that making it with flat textures wont require ultra big resolution

 

That's right, it doesn't require "ultra big resolution". But it still requires more data and more work per rendered pixel than using a mesh-oriented solution, assuming certain other challenges are overcome, which they have been.

Edit: But don't take my word for it. Think through the steps yourself, what is the computer doing at each stage, from CPU to GPU to pixels being sent to the screen? For which approach does each pixel need more texture reads, more calculations on average?

 

Indeed, for something like a fence it can result in less data than a texture, considering the geometry itself is compressed. Not sure how well tiling would work without producing seams at the LOD transitions, however. But this is something that could maybe be integrated into the pipeline itself (tiled meshes).

 

Yeah, that's definitely one of the "other challenges" I mentioned. Nanite and other similar tech works on geometry clusters rather than meshes, though, so a general solution to that must have been found.

Even without tiling the mesh, though, I can imagine people opting for it over a texture-based solution for its other benefits. Judging by install size lately it seem that higher storage size / memory usage isn't considered a high cost...

 

Textures are usually the bulk of any modern game, yeah. Getting rid of the normal map alone is already a nice saving.

 

Also it would be hi rez to achieve "similar quality" even with a trim sheet, because you can get dangerous close to that mesh, so the sharpness needed is a lot. And then you probably need an advence version of POM shader, which is fillrate crazy, the closer you get the more steps are needed, there probably something with SDF to investigate... BUT that's a lot of specific code for just one asset from one asset type.

 

Hi everyone,
if you want something similar to Nanite for Unity, please check this out:

https://www.indiegogo.com/projects/the-unity-improver-nano-tech/

 

Came here to post this! Thank you. Will be supporting this campaign.

 

Anyone interested in this may want to pay close attention to the first paragraph concerning the asset.

When he says a "new rendering system" he likely means a "new render pipeline". If it's a new render pipeline you won't be able to use this with the official render pipelines and may have to customize all of your assets for it and any assets you've bought from the store.

It's likely based off of the HDRP but if you're not comfortable working with render pipeline scripts yourself you will be dependent on him updating them for you.

 

Sorry, but if you do some more research on my youtube channel you will find out that it works with the Shader Graph system and supports HDRP, URP and Builtin-Pipelines, it's not a new render-pipeline!
It's just a different way to render things with one draw call, but it uses the Unity API very closely.

 

I recommend stating this in your Indiegogo because most people are not going to go to your channel to watch every video or read every description.

 

Very cool Chris, impressive that you managed to make this all by yourself! I will definitely follow with great interest.

 

As much as this is exciting, I dont have high hopes. Overall its still Unity asset that can be dumped at some point. But best wishes to the creator.

On the side note...We now need a solo dev to create realtime GI asset

 

All assets are temporary. (Thinking over a long span)
Still, it certainly helps a lot of people. Playmaker, DynamicBone, Gaia, etc ..
Even the features we believe UnityDev is under development
UnityDev may not be under development.

 

In the past I would have said, relying on a single person to provide a product has the way higher risk of it getting abandoned. But seeing the practice of decision making in large companies made me doubt that a bit

In the end the rules to avoid issues are simple:
- Make a proof of concept before you start any project so you know what you have NOW does suffice to finish the game, even if you might do some workarounds.
- (Implied by the rule above: ) Do not make your project crucially dependent on the promise of features you cannot add yourself, being delivered externally in the future.
- As far as personal learning goes, do not focus on a single tech and stay versatile.

 

Some guy does first tries at Nanite Landscape, compiled source form main branch

https://twitter.com/DylserX/status/1533233778554187776

And below Medival demo with Nanitized trees and foliage

https://twitter.com/DylserX/status/1534099535651573760

 

Like this one? https://twitter.com/harrynesbitt/status/1516400219075878917
or this one from Unity graphic engineer but not sure it was created inside unity or custom engine though https://twitter.com/raroni86/status/1535160052369215490

 

Havent seen the above, looks nice. Tough those 2 ppl didnt mention they plan to release assets based on their meddling with realtime GI .

 

Well seeing everyone are currently meddling with ReSTIR from nvidia it might take a while, let's just hope the one from Unity Graphic engineer are implemented into unity with SRP agnostic since it also have runtime lightmap rasterizer

 

https://twitter.com/harrynesbitt/status/1531578816879071232

Thanks for letting me know!

 

My campaign is live now, please have a look:

https://igg.me/at/nano-tech

Thank you for your support!

 

Just seen the video first and gotta say: Wow, I thought your avatar was showing an actor from a Sitcom or something X3

Aside of that, while the price is surely fair for such a feature which is best used in proper studios, I do have to say I feel a bit baited to have read this as advertised as free after the campaign, and now charging $100$ (and $250 for all repos; you mean completely independent assets?)...

If I had a game where that's useful, I'd still consider it of course, but just to play with it (which I believe is why many assets overall are bought), it's rather pricy for Unity standards (which admittedly are very low) :/

Anyways, wish you lots of success!

 

Ive been toying around with UE5 recently, especially the Matrix demo. Seriously impressive tech! I think the demo is a little too rigid to mould it to something else but its been an excellent learning resource as a diorama for getting into this technology.

 

The man got unleashed

@Nexusmaster I wish You all the best with the campaign, it will be rough because 1 milion euro is not small amount of cash to ask for especially in amids of recession. But this, if released, will be a big improvement for Unity and atm Unity needs ppl that can improve it .

 

Seriously check the making off on the unreal youtube channel, good stuff and engine agnostic for the most part!

 

I will, thank you!

Ive been dabbling with both UE and Godot for a little while but now have the opportunity to dive more into both.

 

You will soon master the triforce
Force (Unity)
Wisdom (Unreal)
Courage (Godot)

 

I don't know if I would consider the engine that chooses different names for standard features to be wise. Just as an example they decided that "raycast" should be "linetrace" and that ECS is "entities, fragments, and processors".

 

Godot was obviously courage the small guy going for the big behemoth.

So it was toss up with unity and unreal, and given how we complain here about the direction, they had to be ganon... I mean the force of their huge install base thanks to mobile game.

Wisdom is also experience, and unreal has more of that than other engine, it's mature, and any foolishness were from their youth, inherited from back when 3d was new and unreal 1 was a breakthrough in 3d rendering.

[/geeking]

 

Haha, you too saw just this recent vid where a dev pokes a bit of fun at those names on UE side?
https://m.youtube.com/watch?v=dphuMHYH_VY

 

and up is forward and forward is up... or something

 

The modern kick all others butt engine with cutting edge tech uses pre-computer paper blueprint axes.

 

it's like it really doesn't matter i guess

 

In a blueprint the x and y axes were parallel to the edges and you extruded walls upward along the Z. In computers x is left to right, y is up and down and z goes into the computer screen faking the z axis. Most 3DCC use Z forward these days with Y up. So any models you need to control rotations on have to take into account the axes were flipped and what was meant to be forward is now up..maybe..Since I never got to see a camera I have no clue if they made the camera look along it's Y axis. It is just a big PITA to unwind rotations with gimbal lock coming into play at orthogonal angles.

 

It kinda does. If you started with DirectX or OpenGL, you're used that X is right, Y is up.
This is compatible with cartesian coordinate system used in school level trigonometry/geometry.

Now, Z is forward in Dx and backwards in GL.

Unreal has X forward, Y right, Z up. This probably originates from CAD systems build on computers that had X right, Y down for screen. This sort of coordinate system was likely used in early computer because memory layout followed movement of CRT screen ray, so it made sense to have Y0 for 1st scanline at the top. YMax for the last scanline at the bottom.

And X-forward matches layout often seen in blueprints.

Spoiler

This car is turned to the right, and it matches unreal default orientation (X axis forward, Y axis right, assuming screen axis is down).

However, if you're already used to DX/GL convention, this sort of orientation is extremely annoying.

 

That picture is a fantastic example of why axis labels are completely arbitrary. It has 4 images of the car on one page, each oriented differently. Literally half of it contradicts what you're saying, with "forward" of the car pointing to the right of the page, into the page, and out of the page, depending on which diagram you look at. And the page has no axis labels.

Calling the axes X and Y (and Z) is purely a convention, and is no more meaningful than the convention of calling the index variable in a for loop 'i'. It's fair enough for people to prefer to stick to what they're used to, I do too, but that's all this is.

Personally, I'd be all for labeling or aliasing the axes 'r', 'u' and 'f', in much the same way that vectors in shader languages can refer to their components as 'r', 'g' and 'b' for when working with colour data. Edit: Not because I think it's more correct, but it's a (very minor) abstraction we can remove, and it'd kill conversations like this one. Here it's all in good fun, but I've had "serious" versions of this conversation with people on more than one occasion.

 

and yet people are making games with all these different engines. i dont even know what the heck you guys are saying but it doesn't slow me down at all.

 

Splitting hairs and making arbitrary things "matter" so their engine of choice "wins" somehow.

For example, the most important thing to me is that the engine I use has multiple UI systems that are all terrible, to the point I can't decide which one I hate more, in which case Unity wins hands down.