Josh on NV40 & R420

[KimB]

Good point. Do you know if any of the current polybump generators are implementing parallax mapping yet?

I'm pretty sure the UnrealEngine 3 does. I would typically expect, though, that parallax mapping is transparent to the polybump generation algorithm.

 

[Hyp-X]

A model with messed up normals will always screw up TruForm, but I don't see how "poly-bump" style models or any other bump-mapped model should have incorrect normals anyway. This usually only arises from modelling tools that don't bother to duplicate vertices at sharp edges or corners.

If you duplicate the vertices for sharp edges, the N-patch tesselated model will have cracks...

Wouldn't that only happen if your normals aren't perpendicular to the faces? I guess you could have some precision problems, and some sharp intersections are rounded in the other direction.

No, it's not a precision problem.
Think about cylinders.

Anyway, I didn't necessarily mean separating the edges. You could put a degenerate quad in these edges so that you could have multiple normals at one location.

Yes that's the solution to avoid crack.
Unfortunately the normals on the (originally) degenerate quad will be totally fscked up.
And don't even get started about texture coordinates...

Once again never think about cubes - think about cylinders.

 

[Mintmaster]

No, it's not a precision problem.
Think about cylinders.

Yeah, that's what I meant when I said "rounded in the other direction" (other direction of the sharp change). I wasn't very clear with that statement.

I don't think the normals will be that messed up for the formerly degenerate quad, but texture coordinates are definately a big problem. I wonder if zero length normals would work for the cylinder caps? You could use another normal for lighting (passed via texture coordinates)? Anyway, I don't think it'd be wise to use any form of HOS in situations like that, but I don't know too much in this area.

 

[Hyp-X]

Anyway, I don't think it'd be wise to use any form of HOS in situations like that, but I don't know too much in this area.

Subdivision surface is working well with edges.
You can even define edge sharpness - with infinite edge sharpness you get a good cylinder approximation.

OTOH, I'm not sure how it handles mapping discontinuities.

 

[ERP]

Anyway, I don't think it'd be wise to use any form of HOS in situations like that, but I don't know too much in this area.

Subdivision surface is working well with edges.
You can even define edge sharpness - with infinite edge sharpness you get a good cylinder approximation.

OTOH, I'm not sure how it handles mapping discontinuities.

There are no hard and fast rules with dealing with UV coordinates on sub div surfaces. The most common solution is to add the UV's into the subdivision process, so they get hard edges like everything else.

The real problem with and smooth surface constructs (I looked at them for a racing game a couple of years ago) is that the shear number of control points required to represent any "real" (read surface with non low frequency components) surface, coupled with the extra data that needs to be stored, the complexity of authoring and the cost of the tessalation, means that in most cases it's cheaper to store a highres polygon model and much cheaper to render it.

What you do get out of them is being able to get very close to the model without it becoming polygonal, but you can get pretty close to a 25,000 polygon model before it starts to look bad.

 

[Dio]

The real problem with and smooth surface constructs (I looked at them for a racing game a couple of years ago) is that the shear number of control points required to represent any "real" (read surface with non low frequency components) surface, coupled with the extra data that needs to be stored, the complexity of authoring and the cost of the tessalation, means that in most cases it's cheaper to store a highres polygon model and much cheaper to render it.

Yes, I found this as well. It's particularly true of Bezier surfaces which can require truly ridiculous numbers of control points. NURBS are a lot better.

 

[ERP]

The real problem with and smooth surface constructs (I looked at them for a racing game a couple of years ago) is that the shear number of control points required to represent any "real" (read surface with non low frequency components) surface, coupled with the extra data that needs to be stored, the complexity of authoring and the cost of the tessalation, means that in most cases it's cheaper to store a highres polygon model and much cheaper to render it.

Yes, I found this as well. It's particularly true of Bezier surfaces which can require truly ridiculous numbers of control points. NURBS are a lot better.

I agree nurbs are better, but for any real object you need to be able to trim, and that's a really expensive opreation.

The other problem we found with nurbs was that the artists didn't actually create "good" nurbs models , just models good enough to hold up in the prerendered stuff and having them actually "finish" the models was a substantial amount of extra work. The primary thing they did was not join adjacent surfaces, because it was difficult to smooth them, and these seams would show up, but only from some angles.

 

[GameCat]

That's the great thing about subdivision surfaces, it's much easier to add detail where it's needed. Any HOS that only supports quad patches will suffer badly from to many control points. You really need triangles (without pinching and cracking) to be able to vary detail over the mesh

 

[ERP]

That wasn't really what we found, we had models built using both loop subdiv surfaces and also catmull clark surfaces, both with support for variable edge hardness.

There were two things we found surprising, the first was the shear number of patches we ended up with, the second was the percentage of extrordinary verts on the surface. Both were MUCH higher than we had predicted. I think the main problem is that trying to get an exact reproduction of a complex compound curve just take a lot of points.

I was lucky enough to see some real CAD data from a couple of car manufacturers during this process, and theyhave literally 10's of thousands of nurb patches to create the original curves, so expecting to get a close approximation with 1000 or so is very optimistic.

 

[ERP]

That wasn't really what we found, we had models built using both loop subdiv surfaces and also catmull clark surfaces, both with support for variable edge hardness.

There were two things we found surprising, the first was the shear number of patches we ended up with, the second was the percentage of extrordinary verts on the surface. Both were MUCH higher than we had predicted. I think the main problem is that trying to get an exact reproduction of a complex compound curve just take a lot of points.

I was lucky enough to see some real CAD data from a couple of car manufacturers during this process, and theyhave literally 10's of thousands of nurb patches to create the original curves, so expecting to get a close approximation with 1000 or so is very optimistic.