Curious... what is it? New type of prim???

I really doubt this is done using height maps, which is how terrains are sculpted. What you're talking about are bump maps, and SL limits your use of them to the drop down menu options. The reason is that you can only have one alpha channel on a texture, and that's reserved for transparency. (or rather, SL only recognizes one alpha channel on a texture... grr)

I suspect this is a new prim type, and the object in question really does look like a sphere originally - but it's all conjecture at this point.

As and Os
This link was given on another forum.

No. Firstly bump maps are different from displacement maps, secondly you can use a separate file rather than a channel in the main texture file (of which I've never seen more than 4). Advanced shader-based displacement actually uses a single separate file for both hight and lighting (normal) info, although I've seen implementations using all 4 channels for height data.

Still doesn't tell us how it's done though.

Ack, I've got too much to do to be getting distracted by this. Damn you QDot or Qarl or whoever's responsible.

Looks nice!

I'm guessing it's a form of nurbs. If it was vertex editing then they may as well just give us an Upload Mesh option. As far as I know, hell hasn't frozen over yet, so an Upload Mesh option isn't gonna happen.

So it looks to be a cross between vertex editing and nurbs.

There will be a simple cage of control points that will be stored along side each primitive. Each control point will deform the underlying vertices.

It can't be displacement mapping because the arms of the little starfish are pointing downwards towards the ground. Displacement mapping only determines how far polygons are shifted along their normals. (I think )

That's my guess!

Do I win?

hm, one of my rendering programs can spit out many many alpha channels of various sorts of data.

I have Photoshop files with multiple alpha channels. RAW files, which the terrains require for upload, supports multiple alphas as well - and its a 13 channel format for uploading them to SL. So that's surely not true.

Targa format is limited to four, forgot about that. But its a limitation of that format, that's all.

That aside, terrains are not prims. Terrains are heightfields and use grayscale height maps.

I'm fairly (but not entirely) certain that prims don't function like that. Yes I am aware that shaders can use separate files for bump/normal/displacement mapping. The fact is SL doesn't let you use more than one texture per face for a prim, and you're limited to largely useless bump mapping choices in the texturing menu. SL does have bump mapping, it's just very primitive. They do mention possibly moving to something more advanced in the future on one wiki entry, I hope that eventually happens.

I'd like to have more choices and the blog from Qarl seems promising in that regard. I hope to see the graphics evolve more here.

No! No!

Rather than a cage of control points. It will be a list of deformations!.



Possibly maybe

Ah, I see. I understand there's no technical limitation to the number of channels you can have, hadn't come across files that use more than 4 but obviously there are then. I don't get how you have multiple alpha channels though, is that for advanced lighting or something?

Technically terrain is a patch that's deformed by a heightfield.

That's simply what LL have decided to let us do, there's no reason more features couldn't be added. For using a displacement map on prims it would tessellate a face (possibly) then adjust the verticies (or pixels if shader-based) for that face depending on the height map. It's a pretty straight forward way of doing things.

2k Suisei; I've seen some methods (generally involving multiple heightfields) that allow for things like what's shown, but I'm leaning towards nurbs atm too.

http://secondlife.com/knowledgebase/article.php?id=288

all sorts of stuff. water height, flying allowed, landmarks allowed, subdivision of parcels, etc etc.





which is not a prim, as far as I know.

bump maps just change how the lighting occurs across a normal. Which is what the grayscale maps in the bumpmapping do. Terrain height maps actually *displace* a field of dots. But the prims aren't a flat field of dots, you can cut them, hollow them, make holes in them. All things you *can't do* to a height field.

Bump maps do no displacement at all, just a trick of the light. Normal mapping is better, but it's along the same lines still.



yes, they could likely easily give us the ability to specify a bump mapping texture, and the only reason I can speculate why they haven't allowed this is they were afraid of even more texture lag.

From what I see here - I would speculate there's some tech they've applied to a prim to allow you to extrude it. What I'm looking at, on closer inspection, seems like an extruded and deformed sphere. There's several ways to do that. I can make a vague manlike shape in Silo very quickly with subdivision surfaces, or it could be something as simple as metaballs where you can drag parts of the surface in and out using modifiers. The latter is more crude, but likely more accessible to people not familiar with 3d modelling.

Having used programs like Rhino and Amapi in the past, I think NURBS are pretty difficult for average people to learn and likely not that easy to implement in SL, and I doubt that's what they are.

Okay, we both know roughly what we're talking about. I still don't understand why all those channels are called alpha channels (or why you're still talking about bump maps), but I guess that's irrelevant. What I'm getting at is that the heightfield is the data in (one channel of) the RAW file and an equivalent could be applied to a tesselated prim mesh almost as easily as the terrain patch, it's just a case of moving vertices (or pixels for a shader-based method, but that's more complex) along their normal.

For the NURBS implementation I was thinking a NURBS patch would be generated for each face from the prim extrusion algorithms and the user would then have some tools to adjust control points in a sculpting type way (somewhat akin to the land editing tools).

Still this is all idle speculation, innit. Roll on Friday!

the reason I'm talking about bump maps is because that's what they were. There was never the kind of prim displacement you're talking about, that far back in time. For some reason they ripped out the ability to set your own bump maps, why I have no firm idea. But when messing with textures, you do realise that the transparency and bump/shiny conflict. That is, if something is set transparent to some degree via the menu or uses an alpha transparency map, it can't be shiny, or have a bump map. and vice versa. So for some reason they conflict, and I suspect it has something to do with it only recognising one alpha layer and applying the bump/shiny to the same layer somehow. I wish I could describe it better than I have. I wish this situation wasn't so.



Sounds like a control cage. Doesn't have to be NURBS, though. I work with a control cage around subd polygonal models all the time.

Looks like it's got something to do with spheres then.

Actually, thinking about it, I reckon the Patrick(?) shape could probably be achieved with a sphere using a displacement map. I'm still curious about why one is shown with a normal map vis on it though. Perhaps it's used for rotating normals in the deformation, that'd make sense.

I know what you're saying, but unless it's using techniques that are only just starting to be used in commercial games (and that, I'd assume, a lot of SL user's computers wouldn't be able to handle) it's altering the mesh, not the texture. I shouldn't have thrown the stuff about shader-based displacement/occlusion mapping really, it's just confusing things and more of a wishful thought. Oh, and I never suggested SL ever had any displacement mapping on prims before now.

Not quite a control cage, geometry is generated from NURBS data rather than altered by it as a control cage does. I was thinking NURBS would probably use less data (and be more scalable visually) than a mesh deformation, although when I think about it more I don't know if the extra processor load would be worth it.

Okay, three posts in a row; bad form, I know.

Anyway, I was just looking at the Patrick pic again and I reckon the normal map on one of the models is showing the normals from a sphere. Also, check the shading on the front model's left leg - looks like a mesh deformation to me.

So, current hypothesis is it's a deformation map. Makes sense since it could be edited in the client quite easily (I still reckon 256x256 resolution surface click location should be pretty easy).

FFS, I'm really wasting faaar to much time on this.

It's probably a new prim type that just looks like a sphere, initially.

I don't care what it looks like, as long as I can play with it like putty.

eta: won't these things be a bitch to texture?

But what's with all the cube references?

That's my best guess of the implementation right now, sounds fun.

Looks like it could be a bit difficult, I expect it keeps the same UV from it's original shape, but you could make it easier by ripping the mesh and baking a texture for it.

That can't be a normal map. The color doesn't correspond to the deformations at all. Despite it having similar colors to a normal map, I think it's just a pretty texture.


Also, the top of his head curves forward towards the camera. That wouldn't be possible using a normal mapping approach.

I'm standing by my "Deformation List". With a deformation list, if you deform just a single area of a sphere slightly, then SL would only have to store the info for that single deformation. Which could be described in just a few vectors.

With your normal mapping idea, you would have to save a full texture regardless of the amount of deformation that was carried out.


So there!

well, as anyone who is familiar with subd surfaces can attest, you can subdivide a cube to give you a sphere inside that cube cage

three levels of subdivision. sphere inside a cube

silo screenshot.

http://www.flickr.com/photos/hypatiacallisto/473757656/

But you wouldn't have enough control points to make that starfish with just a cube.

that's why you can subdivide it, extrude it, etc. Just about all my models start off their virtual existence as the lowly cube.

see, like this for example was also, first, a cube.

http://www.flickr.com/photos/hypatiacallisto/154755738/

Note that bumpmaps are part of SL now. From the wiki with a nice note by Ben Linden:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=bumpmap

Cheers
Anjin

Yeah, I'm familiar with box modeling. I think you may be onto something here.

it would be really sweet if it is that.

but I suspect probably we'll have a control cage around the prims, allowing a certain amount of deformation. Even that would be lightyears better than what we have now.

but I don't know. I could get happily surprised.

?

bump mapping in the way it's implemented in SL is really OLD technology. It was OLD when it was introduced to SL. It's even OLDER now.

follow the link in Anjin's post, a few posts up. It's what I vaguely remembered but didn't have time to look up before I had to leave when answering your earlier posting.

I know it doesn't correspond to the deformations, that's why I said it looked like the normal map for an undeformed sphere.


It's definitely a possibility.

I never suggested a normal maps had anything to do with the deformation did I? But good point; I'm thinking my initial ideas that it was a displacement map probably wouldn't be able to produce the results seen without a normal map (if at all). Damned fuzzy thinking.



Good point.

Yes... Really, why are you still on bump mapping? Is this all from my idle wish for occlusion mapping or something?


Anyhoo, I've decided all this stuff is just teaser material and there's no ARG or puzzle or anything so I'm gonna stop looking into it. Also, from a bit of nosing about the web:
So speculate away. Sounds like a damned clever chap.

*swoon* he worked on Riven