Large parabola

Hi

Any ideas how i waould make the perfect arch structure? I've messed around with big prims but am finding them a bit restrictive unless there is something I dont know about them - I mean something not disimilar to the Gateway Arch in St.Louis which is wider at the base and narrower at the top.

I suspect there is some matethmatics involved...

My arch needs to be 30-40m wide and 45-60m high, dont care about prims, but obviioulsy less is more as they say as I need four of these things in my structure. I'm assuming a number of straight segments tapered in but how do I line it all up and calculate it so it fits perfectly?



http://en.wikipedia.org/wiki/Jefferson_National_Expansion_Memorial


Added:
The correct term it seems is "catenary arch"
http://en.wikipedia.org/wiki/Catenary_arch

What do you want the cross-section to be like?
I think I could make these out of 12 sculpties each (for 30x50m final).
Is that too many?

You line it up so that it fits perfectly by using mathematics. Sad but true. You can also do it by eye.

Cadroe Murphy has a good tool called ShapeGen that will make large things out of many prims. I recall that he has a couple of other *Gen devices too. One of those might get you close.

It would be modestly easy (for me or other mathematically minded guy) to create a bad tool that would do part of the job.

As the previous poster suggests, clever sculpties might make for fewer prims and a more perfect catenary, but that would take more cleverness than I possess.

lee

4 options:

1. If you want the absolute lowest number of prims, a single sculpted megaprim would do the job easily enough.

-OR-

2. If you want to build it out of regular prims, you could do it by hand rather easily. If I were to do it, I'd simply grab that picture from your wikipedia link, lay it out full size in SL, and build right on top of it. It wouldn't take very long at all.

-OR-

3. Cadroe Murphy's Bezier curve tool would do it on about 10 seconds, out of cubes.

-OR-

4. You could use multiple sculpts, as Drongle suggested, but I probably wouldn't. The poly count would be absurdly high for a shape that simple if it were made from 12 sculpties. Each (spherical) sculpty has 2048 traiangles in it. Compare that with a cube, which has just 108. You'd need 19 cubes to equal the rendering overhead of one sculpty. Scale that to what we're talking about here, and it would take 360 cubes to cause as much lag as 12 sculpties. You could make that arch look great with a hell of a lot less than 360 cubes. If it took more than a tenth of that, I'd be surprised.

Wow great! I'm chatting to Cadroe now

Now that raises an important point, to which I would like a definitive answer. For sculpties like this, I would only have a small proportion of the available triangles visible. The vertices of rest would be hidden inside and mostly overlaid at a single point. Thus the triangles would (a) be invisible and/or (b) have at least one zero dimension. So the question is whether these two categories of triangle use resources or not. I am sure someone said in a previous thread that zero-dimension triangles were omitted from the rendering pipeline and were thus almost cost (indeed, it is possible to make a 12 triangle cube sculpty that would then be less costly to render than the default cube, although with horrible texture/LOD problems). The invisible ones with all non-zero dimensions I don't have any idea about. I have been working on the assumption that the rendering cost of scuplties depends on the number of non-zero triangles, not the total. Anyone have irrefutable definitive information on this?

That's a good question, Drongle. I don't know the answer with 100% certainty, since its beyond my expertise, but from what I've been told, I'll share what I think I know. If anyone can add to this and/or correct any part of it that is wrong (with certainty), please do.

1. Hidden triangles (with dimension) have the same rendering cost as visible triangles. As far as I know, SL's occlusion culling system works on a per-object, not per-polygon or per-pixel, basis. If any part of an object is not occluded, the whole object is considered not occluded, and the whole thing is rendered. That, of course, includes objects with transparent textures on them.

2. Zero-dimension triangles do indeed have a rendering cost. They're not skpped over in the rendering pipleline; they're just rendered with no size.

In fact, one person I trust, a guy with a much better understanding of this stuff than I have, recently told me that sculpties made with zero-dimension triangles can actually have a significantly higher rendering cost than those without. I don't remember the technical reason he gave, but he said they can be as much as 32 times as expensive. Next time I talk to him I'll ask for the explanation again, and I'll write it down.

What I do know with certainty is that whatever SL actually does do to render those objects, it's unusual. If you capture certain ones (I won't say how, of course), and try to bring them into Maya, you get a warning about impossible geometry, just before the program crashes. I have to assume, therefore, that the way SL recreates the geometry for rendering is substantially different than the way it was created in the source model. Again, I don't understand it. Just sharing observations.


If nothing else, reason dictates that objects with a lot of hidden polygons have to be more expensive from a texturing standpoint than they otherwise would be. In order to get a decent amount of pixels on the visible part, you either need to use a bigger canvas than you normally would, or else you need to repeat the texture a whole bunch of times in order to get one full repeat across the visible part. The latter is far less costly than the former, of course, but either one is more expensive than just wrapping one reasonably sized texture one time around the surface.

I just tried to do some experiments at z=2000m with some example sculpties, but the triangle count was too small to make a difference in the statistics bar triangle info. Maybe I'll have to replicate the a few dozen times!

OK did replicates. I can confirm that the triangle count shown in the statistics bar stays at 2048 per sculpty whatever the hidden/zeroed state of the triangles are. Same count for torus (sphere is 528 and box 10. Of course that doesn't say whether all triangles take up the same rendering time.

Interesting to note that while the fps was off scale most of the time, selecting to edit, making the yellow glow around the selected prim, drastically reduced the fps. This was more marked for my 102-separate-object sculpty (15fps) than for more normal ones (30fps), but substantial for either. Also happened with sphere - so it's not sculpty-specific. The triangle count in the stats bar was not affected - so it's not much of a guide, I guess.

/me ducks instinctively as the discussion flies way over head

Meanwhile the Cadroe lathe thingy works brilliantly - although there is a bit of a learning curve...

hehe

Cadroe showed me a parabole that tapered, but i couldn't figure that out yet.

Feel free to check out my parabolas in game

Just do a search for Nature's Way in game and follow the signs for Dukes Bay - you can't miss it

Thanks for the tips!

Having missed Qarl Linden's office hours, where I intended to ask him, I did some searching through the source files. In llVolume.cpp there is a function that culls (nearly) duplicate vertices, degenerate triangles (with two identical vertices) and equal triangles. I have not been able to confirm that this is called before sculpties are rendered, but I would expect so. This would remove many of the redundant triangles in some sculpties (but not those of zero-dimension that have three different vertices all in a straight line). If this is called for sculpties, the statistics bar triangle counter must be looking at the number before this is done, although it does know when the triangle count goes down because of LOD changes. Oh well, at least I know what to ask him if I make it there next week, and I can suggest adding the three-vertices-in-a-line filter.

Quite possible that this stuff was added recently because of the problem you alluded to - with over-long rendering times for zeroed triangles.

Ah. I searched the whole source and could not find a call to this function "cleanupTriangleData". S maybe it's just there waiting to be used one day, or was found to be buggy. Either way, the above can be ignored, I guess.