Temple Canyon

[greypiffle]

I don't know what happened to this one.... I could have sworn I had some stuff up about it.

Anyway. I've worked on this off and on, for about a year and a half. I sorta got involved in other things and I'm comming back to it.

Here is what I had back then...


View 7 has changed a LOT! I just could not get rid of some bad geometry near the entrance, so I deleted that whole cave and created another one. I will get an update soon.

What I'm working on now is the temple itself. Too many polygons! when I do a walk-through in Truespace, my view slows to a crawl whenever I go toward it.

So... to make it a bit less, I've been working on the various elements.

Here, I've reduced polygons on one of the column types I have


I may replace these with some other ones though.

and here I've worked on the capitol going around the outside



For those who do not know... a point is where two lines intersect to form a "corner" of a polygon.

[Marcello]

Looking good!

What I always try to do is decide where polygons really add something and where I can use textures instead. Sometimes an object is not functionally relevant for a scene, but it is for its looks. In those cases I use textures. I don't think normal maps are working in the current plugin. If they are or will, then those could really help reduce the no of polygons and still get the result you want. Your column could be almos round and flat instead of modelling the snakelike decoration.

Anyone who can comment on normal maps here?

[Lontahv]

We know that normal maps are possible in Plasma; we just don't know if they'll let us use them outside waveset "decals" and wavesets themselves.

Garden has something called a "BumpLutTexture" this doesn't look really like a bumpmap for anything--more just like some kind of texture to enable painting of bumpmaps in vertex paint. So if the thing IS bumpmap related then there is hope for bumpmaps in UruCC, if it's not a bumpmap, then most likey we can't stick the bumpmap feature in PyPRP (because CC wouldn't support them).

Now, I'm kind of puzzled why Cyan would have "bump maps" and not just "normal maps" (except for wavesets). Oh and if we do find out how to make normal maps you'll need to make the object shiny with an env so that you can see the normal-ness.

So, the bottom line is: no normal or bumpmaps currently and if UruCC doesn't support them, there never will be (maybe in MO:RE though hehehe).

[Jojon]

BumpLookUpTableTexture? Sounds like maybe something like a normal map, but some rather custom implementation..? :7

With this realtime graphics stuff, it's quite hard to draw the line on where to reduce mesh complexity to almost nothing and where to have lots of detail - especially when one is used to model every little screwhead on the never shown backside of objects.. :P

For those pillars, if that's not what you have already, try making the cylinders and the spirals separate parts - that's going to save you quite some points and faces and as a bonus will right away give you hard edges at the intersections. You have some...20 segments to the cylinders in the lowpoly version it looks like? That's a good measure, but it may be possible to get away with even a bit less, if you don't expect the player to be standing staring at the pillar close-up, given that the diameter isn't all that large. It's quite surprising how much you can get away with; thanks to the shading and the player's limited attention to each individual detail, a single v cutsection is often enough for a rounded bevel - mostly noticeable where edges are visible.

I guess the only rule there might be to half-follow would be: Player gonna see up close: model/texture carefully, somewhere out in the players peripheral vision: cheat. :P

[greypiffle]

yeah, that is the problem here. The capitol around the outside is far enough away that it probably won't be noticed, but the pillars are right there in your face. you can see from view 2 in the slideshow that they are right there and people can even walk around them.

[Jojon]

Ah yes, looked at it just now, with another machine (this particular ancient computer doesn't do half recent flash :7) and the original age looks low-poly enough -- can't wait to see the caustic simulations in the temple, once you get some light shining on that crystal ball. :)

Most of the beam profile detail should probably work just fine as a texture and there are only two pillars, so I'm sure your polygon budget is healthy enough... :)

[greypiffle]

actually, there are two columns outside and 8 inside! The ones above are the inside ones. The helix on the columns is a double helix, so I may just remove one helix and see what that does, or modify the outside columns a bit (lower poly) and use the modified ones inside.

[greypiffle]

OK - I've messed around, and here is what I have
For the inside columns - the first one is a modification of the original second one

For the outside columns - the last one in this lineup is what I'm going to use, but the open one is a possibility to replace the inside ones.



and here they are again with the wireframe showing.

[Jojon]

Nice. :)

Actually the double helix thing could SAVE you faces. :7 You could use a single closed profile, cutting right through the the entire pillar doing both sides with just six points - eight faces for the price of six, sorta, given that two would be shared between the heli on opposite sides. I truly think that more than 10 points for such a twin profile is a bit of a waste, for realtime stuff; you'll mostly notice the nice rounding, given by any points beyond that number, from the profile of the pillar.

It is also possible that it is I, who go butchering models much too heavily, to reduce polygon count...

I do notice that you have more rounding detail on the bases for the closed version of the new design, but would still expect it to actually use up fewer polys than the open one - did you remember to delete the parts of the eight heli, that wound up inside the pillar, where they can't be seen? (same opportunity to save faces by "shared mirroring" here, by the way.)

[Grogyan]

Sweet!