Hows This For A Feature

doesnt exist yet....

but if we can twist, taper and pathcut ...even sculture prims....why why why cant we do something VERY simple to a prim like offset a hole.

I cant see a real logical reason for why not yet i can see lots of bennifits as the math is already there becasue we can move the prim in space and as a result one can assume that the hole must also have an x/y/z co-ordinate in order to move with the prim. With that in mine we SHOULD be able to say that as standard the hole is at 0/0/0 why can we have a choice to make 0 plus X

Just think ......... the amount of prims it would save on house building etc.

Marty

Not so much, actually. Prims are parametric, and as a result theres very little excess data there... Although I haven't actually taken a look "behind the scenes" as it were, there most likely isn't a location value specified for the hole in the way you suggest.

As you can texture the inside of a hole... (to be fair with only ONE texture all the way round), it must have some position in space ???

It has a position in space as defined by parametric data...

What determines precisely where the hole starts, however, is mostly likely not a simple <X,Y,Z> value, though.

We've been asking for this feature since forever, keep in mind. Lindens have introduced a half dozen new prim features in that time (new shapes, new ways of twisting, flexi, sculpty...), and not this. So its got to be a little more complex.

The reason holes can't be offset has to do with the way 3D geometry is constructed in SL. There's a big difference between how you as a human being see something like a cube and the way the computer sees it. I'll try to explain.

As a human, you look at a box, and you see a six-sided, soild object. It makes perfect sense to you that you should be able to drill a hole into that solid object anywhere you want. However, to the computer, it's not a solid piece of 3-dimensional material at all, but rather a 2-dimensional profile swept around a perpendicular 2-dimensional path. When you punch a hole in the object, you're not actually drilling; you're changing the shape of the profile in order to leave some empty space in the middle of the path.

For a RL analogy, think of it kind of like this. Did you ever take a coin, stand it on end, and spin it? Sure, everyone has. Well, what does the flat coin look like while it's spinning? It looks like a sphere. The coin itself is just a flat circle (that's the profile), but revolve that circle perpendicularly in 3D space, and it appears to draw out a sphere for you (the spinning is the path).

All the prims in SL are made this way, by taking 2D shapes and revolving them in 3D space, just like that spinning coin.

A cube in SL is actually a rectangular profile swept around a square path. When you "hollow" the cube, what you're actually doing is narrowing the profile's shape, so that the inner edge of the rectangle no longer reaches the center point of the path. The result is you're left with some empty space in the middle.

This is why holes can only run along the Z axis of an object, and it's why they can only ever be in the middle. In order to "offset the hole", you'd need the path to change size at every point along the path. That can be done, sure, but it's computationally expensive.


I hope this had made sense. It's a little tough to explain this kind of thing with just words.

Actually all that and more is available to do in unreal editors of the past and the present one for UT3. You can cut, hollow out or do just about anything you want in there. It's SL's engine that is the problem, Linden Labs made a poor choice. I work with unreal editor every_day_of_my_life. The newest version (not released yet) is even better. Again these programs aren't in any way compatible with this game or creating anything within this game. I was just mentioning that all the options people want are possible. The newest not released to the public version of UED let's you do way more than the previous editions and far more than SL can hope for. But be looking in the future from a company out of the midwest to use the unreal tools to produce a game like SL, that will demolish it.

Unreal isn't a parametric engine. SL more or less has to be by virtue of what it is. It's not a poor choice, its a necessary evil.

Depends on what you're optimizing for. The optimization in SL's case seems to be that of describing a given prim using the least amount of data. UT's is for providing the most detail. The CSG operations performed on UT "brushes" result in a polygon mesh for which data on each vertex must be stored. All of the shaping operations on SL prims can be described by a few numbers which the client then uses to rebuild the shape on it's end without needing to be told, for example, where each vertex of a sphere is located.

reposted below

You're comparing apples and oranges. Unreal operates on completely different principles from SL. With Unreal, you're working with actual meshes and the data sets are huge, so of course you can do whatever you want geometrically. With SL prims, you're working with a very small amount streaming information for a common set of building blocks, so while your geometric capabilities are more limited, you can do things with it, communications wise, that Unreal could NEVER do.

With Unreal, the entire world resides on the user's hard drive, and it never changes. With SL, virtually nothing resides on the user's hard drive, and almost all of it changes all the time. The differences between the two couldn't be greater.

So, can Unreal can do lots of things SL can't? Sure, of course, absolutely. But SL can also do lots of things Unreal can't. Try to stream an Unreal world over the Internet in real time, for example, and you'd have a bit of a problem. As Deanna said, the two are optimized for different purposes.



It's not a problem, and they didn't make a poor choice. The way SL is designed is absolutely brilliant. It has its share of bugs, as we all know, but that's a different topic. The essence of what SL is is really, really good. You just can't expect it to do things the same way as other engines that operate on different principles.


If you or this mystery "company out of the midwest" can figure out how to make the Internet operate fast enough to enable an SL style user-created dynamic streaming world to work in real time off something as non-streamlined as the Unreal engine, then God bless you and I hope you conquer the universe. Otherwise, you're just making comparisons that don't make sense.

You WILL be surprised when the unreal 3 engine version of a game similar to SL (already in the works now) is released, and it already can stream in real time. I've seen it, hell guess what event is taking place right now and where I am on my laptop from? Not to mention the new engine (not released publically) is something you lack the knowledge of to support any valid argument, because if you knew it, then you'd be making totally different comments and supporting what I'm saying. I'm pro unreal of course. The new unreal engine 3 is amazing. It CAN do all the things SL does now and much more. This of course is dependent on what modifications to the engine are made. You'll have to wait until it's released although if you do work in the industry and know where to look you can see the tech demos of the new u engine doing the EXACT same things SL can do but with much more flexibility. I'm not talking about 2.5 and lower, although some modder who got hired by Epic, did make streaming real time changes using brushes with 2.5. He also made it so you could completely model and import in models (meshes) the real way (not the qarl way.)

and LL.... they did make a poor choice. If you look at the older version of unreal engine it's possible to do as I said someone had done, what SL does now. Don't look at Unreal Tournament for this knowledge but modded versions of the engine. Comments like this "With Unreal, the entire world resides on the user's hard drive, and it never changes. With SL, virtually nothing resides on the user's hard drive, and almost all of it changes all the time. The differences between the two couldn't be greater." show what little (no cheap shot at you) knowledge you know about the engine, especially 3. And as I said someone achieved this on 2.5 and the modification got immediately pulled from public space and taken to a private studio. Not to mention evey other game I've played using the engine LL decided on also stores all it's assets on your hd. Modified though (like SL) is a different story. Ubisoft and I quote "heavily optimized" the unreal 3 engine for their new titles coming out later this year. The engine is that flexible you can do -anything- with it.

I'm not trying to sound like I'm starting a fight (english is my second language) and I'm not posting again, I was just sharing some info. Look for it in 2008-09. There's actually a couple of unreal 3 engines being used by different developers to do the very things SL can do. The End.

You've got me intrigued now. If what you're saying is true, then it's great news. I'd love to learn more about it. I'm still a little skeptical, but if I'd be happy to find out for sure that I'm wrong.


I would like to know what you mean by "every other game that uses the engine SL decided on" though. My understanding was that SL's engine is unique, and that it was developed from scratch by LL. I'm not aware of any other game that uses it. So what do you mean?

Wrong url hold on, it won't link here. There's also something else. Although if you attend the convention where the awards are given, Unreal and several others beat out the engine SL uses. I'm trying to get a very close friend to give me the exact technical info on the new game being developed using unreal 3, or rather it's capabilities to do what SL does but better. Some information can't be posted though. I'll try to post back.

Havok is not SL's engine.

Havok is just one backend SL uses for one part of the process.

If you're saying that UT has added support for parametric solids, that's great. It will save storage space and bandwidth for maps and resource packages. But that doesn't mean LL made "the wrong choice" by using parametric solids from the beginning. SL and UT are very different platforms with very different uses.

If that's not what you're saying, you'll have to clarify.

actually I had posted to urls but when i clicked one it didn't link, since it's to a developers forum only, you'd need an account and status to see it and I might get into legal issues posting that info.

I can only clarify so much on the new unreal 3 engine and what modifications the studio that licensed it is doing. The game using the new unreal 3 engine, is being developed. Although as I said someone who worked with WASTE and U2.5 was able to put together something that worked exactly like Second Life does now. This project was moved up to the Unreal 3 engine.

And yes they are different platforms but the unreal engine CAN be used for anything. That's the whole charm of the engine. So many companies are now using u3 (and the previous 2.5) because it's such a friendly engine to take and transform it into literally anything.

As an aside, I've seen other claims of using a traditionally FPS-oriented engine to "Do what SL does". Most commonly cited is Garry's Mod, which is almost as completely unlike SL as it can be while having a sandbox/toolkit element.

As before, I'll believe it when I see it.

And in either case, saying LL made a "mistake" is stupid. You say this game will be out in 09. That's a ways away. You may not have noticed, but SL has been around since 2003. It was early development as far back as 2002, I think, but I could be wrong. Even if your engine exists now, it certainly didn't then, nor did that capabilities needed for such an engine in terms of hardware and widespread bandwidth.

Not really relevant. SL's graphics engine is pretty much an in-house affair.



And unless Unreal 2.5 supported parametric primitives (It did not, in any incarnation I'm familiar with, and I've never heard anything to suggest Unreal 3 does either, in point of fact), it does not work "exactly like Second Life does now". Parametric modeling is not just an empty buzzword, in this case. It's a very specific type of modeling with a very specific implication, particularly bandwidth.

I didn't see whatever URL you had posted, but if Reitsuki's response is any indication, it sounds like maybe you're confusing the Havok physics engine with SL's main engine. The two are entirely different things. Havok simply handles physics calculations on the server side. It's just one component of what makes SL work. The main engine that makes SL actually be SL is proprietary, and was written by Linden Lab, as far as I know.


Beat it out for what? Some award? I don't see what that has to do with what we're talking about, sorry.


Thanks. I'd really like to know what it is you're talking about here.

A little quick Googling led me to a some vague info about an unnamed project by Realtime Worlds that may or may not be a virtual world, and that they may or may not have licensed the Unreal 3 engine for its development. Is that what you're talking about?

I also found that NASA is dabbling with Unreal 3 in an attempt to create a virtual world of their own. It's doubtful that that one will be doing anything like what SL does though.

The unreal engine is used far far far beyond just fps games. The fact you don't know this, kills the argument. The engine (not the game unreal tournament 99, 03.04 and 3) the engine is what I am talking about. It's already fact anything can be done with it. The medical industry is even using it right now. Someone had created something just like SL using the older 2.5. The 3 engine used for a plethora of gametypes most NOT fps, already is being used for an SL like game.

I'm quite aware of what the Unreal engine is used for, actually. Believe it or not, I'm not ignorant of what goes on in the computer game industry, having followed and worked in it for almost 10 years now.

I posted to urls one nothing to do with havok, the other havok. The first url I had to take down it links to a forum I can't share.

Also the game being worked on is not called Realtime Worlds or the Nasa project. It's not even named yet. The name is undecided.

Well, if you can code, why do you try to add the unreal engine into the client?

Well then you'd know it's not used for just FPS titles. FAR FAR from it. There's many studios that have grabbed the engine, but aren't announcing much other than game types which haven't been FPS at all. Actually if you are at E3 right now (this week) you'd be able to see some of these closed door announcements. It's only because I saw today first hand this new "game" that works just like SL, using this engine, and seeing this post that prompted me to also post. The best thing is to just wait. You'll see it when it's out. I can only convey very little about it.

I don't think it kills the argument. I also don't think that Reitsuki meant to imply that the Unreal engine is only used for FPS games. He only said that it's "traditionally FPS-oriented", which it is. Sure, it can be used for all kinds of other things, but that doesn't negate the fact that it was originally intended for FPS games.




For clarity, I didn't say the game was called Realtime Worlds. I said it was an unnamed project being developed by Realtime Worlds. Realtime Worlds is the name of a game company, not the name of any of their products.