I wonder how feasible it would be to smooth 3d models... Unfortunately it may not be something easily done in the core without impacting compatibility, so it may have to be GPU plugin specific. Does anyone here who knows who I'm talking about know how easily it could be done? Like say you have a 90 degree angle, and you want to break it into a set of three 120 degree angles? My math is probably wrong, but I don't have any program to try this with or a protractor with which to do it manually.
3D Interpolation
- Thread starter Nemo
- Start date
Tagrineth
Dragony thingy
Yes, what he's suggesting is something exactly along the lines of TRUFORM.
The thing is, using TRUFORM would severely impact bounding regions on models... and, the thing about TRUFORM is that applying it 'automatically' to the whole scene makes some things end up looking ridiculously puffy, though some things do end up looking better... the main problem is that N64 games aren't aware of the technology at all, so TRUFORM would have to be applied to EVERYTHING to an equal extent. In games which are TRUFORM-aware, the devs can special-case surfaces and set them up so some don't get any, some only get some interpolation, others get a lot.. etc.
But anyway, no, you can't raise the polygon count on any N64 games without EXTENSIVE work. Not worth the effort.
The thing is, using TRUFORM would severely impact bounding regions on models... and, the thing about TRUFORM is that applying it 'automatically' to the whole scene makes some things end up looking ridiculously puffy, though some things do end up looking better... the main problem is that N64 games aren't aware of the technology at all, so TRUFORM would have to be applied to EVERYTHING to an equal extent. In games which are TRUFORM-aware, the devs can special-case surfaces and set them up so some don't get any, some only get some interpolation, others get a lot.. etc.
But anyway, no, you can't raise the polygon count on any N64 games without EXTENSIVE work. Not worth the effort.
- Thread Starter
- #4
How about deciding whether things that get the interpolation or not is based on vertex count of each side? Obviously squares, pentagons, etc. shouldn't, but something with 20+ vertices should. Also, could check for the length of segments, possibly. Excessively long segments don't get interpolated. You also have to consider the fact that all filters have some shortcomings, there's no way of getting rid of all of them.
Tagrineth
Dragony thingy
Nemo said:
You could have a large cube that uses meshes instead of single pairs of triangles, that could easily rack up 20+ vertices.
It all depends on what you're rendering, and there's no catch-all.
Remote said:
In the best case scenario - where all the models are designed to get the maximum benefit from it, etc.
N64 games simply aren't ready for TRUFORM, unless someone were to go through and mark EVERY SINGLE MODEL for degrees of interpolation.
- Thread Starter
- #8
Remote said:
Well, to be honest I'd never even heard of TRUEFORM or any similar system. There was an interpolation discussion started in the 1964 screenshot discussion, and I brought this up, but then decided I would make a new thread rather than cluttering up that one. I'm a newbie to N64 emulation (Started maybe a year or so ago, but never got as interested in it as I did with SNES. LLE just interests me more.) Oh well, if it's not feasible, it's not feasible. I was just curious.
Tagrineth
Dragony thingy
Kolano said:
You don't understand - you'd have to go through and mark every single object in the game for degrees of TRUFORM (there's no E, btw) if you didn't want anything to look screwed up. It isn't a matter of difficulty, it's a matter of time and legality.
The other thing is collision detection. The bounding boxes won't account for the new mass. =P
Tagrineth said:
I think I do understand. All I'm saying is that there are users that would be willing to go through and mark objects if there was some interface to do so, myself included. Even if only a few objects could be marked to have truform applied (like player characters) it would be good. If there is something about the way the N64 handles object lists that would make marking/tracking them difficult I understand. If so could, someone please explain.
As to collision detection, I'm under the impression that for many things in N64 games, collisions are detected along the objets bounding box not the objects actual polygons. In anycase, I'd be willing to accept slight errors in collision detection.
Also could you explain the legal issue you refer to, Tagrineth. If the graphics plugin is already processing these lists of objects, how would applying truform (or similar algorithm to them) cause an additional legal issue? Why is this a legal issue, when applying anistropic filtering to textures is not?
Tagrineth
Dragony thingy
Kolano said:
Oh, so you like clipping errors? I don't. They bug me. Then again, most N64 games aren't too complex about them.
Special case code to that extent in emu -> Encouraging players to use emu for said copyrighted code -> Begging for legal action.
Aniso can be applied to anything with no problems, unlike TRUFORM.
Reznor007
New member
Aniso can cause problems as well. At least in Diablo 2 it makes some things unreadable 
As for Truform, it won't cause any GAME errors. Collision detection is done by a bounding box, which doesn't care what is inside of it. Visually, there might be problems though. I think even Goldeneye bases its hit detection on a few bounding boxes, and not the model itself(just look at DK mode).
As for Truform, it won't cause any GAME errors. Collision detection is done by a bounding box, which doesn't care what is inside of it. Visually, there might be problems though. I think even Goldeneye bases its hit detection on a few bounding boxes, and not the model itself(just look at DK mode).
Tagrineth
Dragony thingy
Reznor007 said:Aniso can cause problems as well. At least in Diablo 2 it makes some things unreadable
Diablo 2 isn't really a 3D game, anyway. Its "3D accelerated" mode does an N64-esque 'map surfaces in 3D for a parallax effect', meaning every object is a texture... that's why everything goes all puffy with Aniso, and that's pretty much what TRUFORM does to a 3D game.
Never said it'd cause game errors, but the bounding boxes are -ideally- aligned to the models, and if the models change...
Reznor007
New member
The thing with Diablo2 is weird though. All of the polygons are faciring directly towards the screen, so aniso shouldn't affect it.
As for Truform, the game will play 100% as normal, the models will just look different. You can test this idea with Quake. Load a large player model, and it will walk through walls/ceilings if it's big enough, because the bounding box is still the same size as normal. The game engine only cares for the predetermined bounding box, the graphics engine is separate.
As for Truform, the game will play 100% as normal, the models will just look different. You can test this idea with Quake. Load a large player model, and it will walk through walls/ceilings if it's big enough, because the bounding box is still the same size as normal. The game engine only cares for the predetermined bounding box, the graphics engine is separate.
Orkin
d1R3c764 & g1|\|64 m4|<3R
As Clements already mentioned, I had actually experimented with TruForm (implemented in software) waaaaay back in a D3D plugin I was writing. It worked pretty well for some things (Mario's head has never looked so smooth), but it made things sorta unplayable in-game, in SM64 anyway (the only game that plugin supported).
The problem was that it smoothed the terrain as well as the objects, so you ended up walking through hills alot because the game engine was still doing collision detection with the non-smoothed polys.
Since then I have given it some thought, and I've come up with a couple solutions that might make it feasible. First, make it ignore polys with a matrix-stack depth below a specified number. This solution would depend alot on how the game handles transformation, but the idea is that the terrain will usually only be transformed for view (matrix stack index of 0), while characters and objects would be transformed into world coordinates, and then to view (matrix stack index of at least 1). I haven't actually tried it to see if it would work, though...
The other solution I came up with is to give the ability to scale the amount of smoothing done to the polys. This would allow the user to find a balance between improved quality, and clipping errors.
Another problem is that I can't use the TruForm implemented into ATI's drivers because I have to do transformation in software to properly emulate the N64's transformation. This means I have to implement it in software, which can get kinda slow.
Anyway, that's as far as I've gotten into it. I may try to introduce poly-smoothing in future versions of glN64, but no promises.
Orkin
The problem was that it smoothed the terrain as well as the objects, so you ended up walking through hills alot because the game engine was still doing collision detection with the non-smoothed polys.
Since then I have given it some thought, and I've come up with a couple solutions that might make it feasible. First, make it ignore polys with a matrix-stack depth below a specified number. This solution would depend alot on how the game handles transformation, but the idea is that the terrain will usually only be transformed for view (matrix stack index of 0), while characters and objects would be transformed into world coordinates, and then to view (matrix stack index of at least 1). I haven't actually tried it to see if it would work, though...
The other solution I came up with is to give the ability to scale the amount of smoothing done to the polys. This would allow the user to find a balance between improved quality, and clipping errors.
Another problem is that I can't use the TruForm implemented into ATI's drivers because I have to do transformation in software to properly emulate the N64's transformation. This means I have to implement it in software, which can get kinda slow.
Anyway, that's as far as I've gotten into it. I may try to introduce poly-smoothing in future versions of glN64, but no promises.
Orkin