Any way to get rid of these lines?

[Josh Susanto]

I've split a 2048 image into 4 parts at 1024 and put them onto adjoining prims.

I'm seeing lines at the junctures, though. I've tried subtle adjustments of all kinds, but I still seem to have these seams.

If I can get rid of them, that will open some doors for me creatively, because I can produce nonrepetitive textures like this in basically any size and then cut them up to make massive adjoining surfaces with basically as many prims as one might like to devote to such a surface times 1 million and more pixels each.

Please help.

[Marcus Hancroft]

Howdy, Josh! 

It looks like that texture isn't seamless.  I would start there and make sure it IS.  If you don't know how to make a texture seamless, let me know and I can do it for you. 

Of course if the texture IS seamless, you gotta make sure the prims are aligned with precision or it won't look right either.  There are a couple of tricks to getting them perfect too so if that's the problem, I can help you there also. 

Let me know!

[Chelsea Malibu]

are you trying to cover 4 prims with the same texture but just cut it up?

Here is another way to do that.

Set each prim textures to .50 in scale.  Then move the postions to .250 and -.250 depending on where they are.  This is something you need to play with but it will take the same texture and place it over all 4 prims seemlessly.

One larger textures is better than 4 smaller ones since every object has delivery overheard.  Less HTTP request = faster rez times.

[Marcus Hancroft]

---

Chelsea Malibu wrote:

are you trying to cover 4 prims with the same texture but just cut it up?

Here is another way to do that.

Set each prim textures to .50 in scale.  Then move the postions to .250 and -.250 depending on where they are.  This is something you need to play with but it will take the same texture and place it over all 4 prims seemlessly.

One larger textures is better than 4 smaller ones since every object has delivery overheard.  Less HTTP request = faster rez times.

---

This ^ is an excellent suggestion too, Josh!  Try this and I hope it solves your seam problem!

[Kwakkelde Kwak]

I agree, and there's really no reason to use 4 1024 textures, expecially with one looking as blurry as the one shown. That's just an overkill in memory use.

[Drongle McMahon]

Are we looking at two pictures of the same thing here, with the upper one a closeup of the center? If that is the case, then I would guess one or both of two things: (1) the seam effect may an edge-effect in the interpolation used when the texture pixels are smaller than the on-screen pixels. (2) it may be an edge artefact from the jpeg2000 compression used by the image uploader. If it's the first, then have you textured the parallel touching edges where the prins meet with the same texture, appropriately stretched and mirrored, in such a way that the texture continues around the edge? That's a guess, but might help. If it's the latter, I can't think of anything you can do about it.

@Marcus ... If he made the textures by cutting up a larger one, then I guess the should automatically join properly across the cuts, even though not seamless in the  usual sense?

eta: see below. I can't find either of these artefacts with box prims.

[Chelsea Malibu]

4 prims, 1 cup..i mean, 1 texture.

[Kwakkelde Kwak]

One other thing it could be.... is lighting. The textures seem to be tiled correctly. It just looks as if the light hits all edges differently. Are the four objects boxes, sculpts, mesh?

I have had a similair issue with local lighting before, but only when the prims aren't the same size....

 

oh edit..the textures do NOT seem to line up..... still it looks like the light hits the edges differently..I would expect this behaviour in sculpt boxes....both lighting and non matching textures. Anyway..personally I'd do it like Chelsea suggested..Hi Chel btw!

[Marcus Hancroft]

---

Drongle McMahon wrote:

@Marcus ... If he made the textures by cutting up a larger one, then I guess the should automatically join properly across the cuts, even though not seamless in the  usual sense?

---

I think they would have to be rotated and "flipped" properly to make them actually seamless though.  At least that's one of the ways to make a texture seamless in Photoshop or Gimp. 

[Kwakkelde Kwak]

---

Marcus Hancroft wrote:

---

Drongle McMahon wrote:

@Marcus ... If he made the textures by cutting up a larger one, then I guess the should automatically join properly across the cuts, even though not seamless in the  usual sense?

---

I think they would have to be rotated and "flipped" properly to make them actually seamless though.  At least that's one of the ways to make a texture seamless in Photoshop or Gimp. 

---

 

I think you missed the comment it was a texture cut up into 4 pieces, that makes it line up alright..well that's what one would expect anyway:)

[Drongle McMahon]

Yes you are right. I tried to reproduce the artefact with box prims and didn't see it at all. On the other hand, if these flat pices are sculpty planes bent over at the top to make two sides, that is exactly the shading artefact you would expect. The solution would then be to coalesce the rows of vertices at the bend. How many rows depends how mant LOD steps you want to avoid the shading artefact for. High only, two rows; medium, four rows (three if you choose them right); and so on.

The problem is that the edges of the applied textures would get lost in between the squeezed vertices. So it would be necessary to adjust either the textures or the repeat and offset in SL, to compensate for that and get them to join up as expected.

eta: actually, since they are huge, you can probably ignore LOD switching.

Needless to say, using a sculpty for a flat plane would be extraordinarily inefficient for the rendering engine* (i.e. laggy), even compared with a box prim. A mesh would be the most efficient (four triangles for two sides, no problem with shading artefacts, no need for texture adjustment). On the other hand, if the final thing is undulating, a sculpty is as efficient as a mesh and cheaper.

* Actually, I am being unfair. If you use an 8x8 sculpt map (4x4 quads), the sculpt would only have 32 triangles, which is much less than the 108 of a box prim. But who uses 8x8 sculpt maps?

[Chosen Few]

As others have stated, there's absolutely no reason to make that particular texture so big.  Overkill doesn't begin to describe it.  It's a cloud pattern, for crying out loud!  It would look almost idential as a single 256x256, while using just 1/64 of the video memory.

At 2048x2048 (or four 1024x1024's), the image consumes a whopping 12 megabytes of video memory, whereas it would be just 192 kilobytes at 256x256.

I certainly hope you just put that one in there as an example, to test the concept of texture slicing in the manner you described, and that that particular image is not the one you plan on using.

 

In any case, those kinds of lines will almost always happen whenever you try to chop up a texture and apply the individual slices to multiple prims, instead of spreading a single texture across all via the repeat and offset settings.  The reason is because SL does not clamp textures.  It tries to tile everything.  So, you always get a small trace of the left edge showing along the right edge, the top edge showing along the bottom edge, etc.

[Josh Susanto]

Thanks to all who have responded.

The (next) short term goal is to be able to produce a 16-prim object with a continuous image of 4096x4096 on one face.

The prims I'm showing are normal box prims, each with a single texture cropped out from a 2048 image.

The build tool says they are perfectly positioned and correctly textured.

I tried both kinds of texture mapping, turned full bright on and off, etc., etc.

Could this be a compression problem?

It's going to be a shame if there's just no way to make this work, because I can produce textures like that at 4096 or larger pretty easily. I don't have some kind of fractal plugin, but I find that explode in Irfanview does something similar if I keep sizing the dimensions up double before I explode.

Start with a 2x2 image with random pixel colors if you're curious.

[Chosen Few]

---

Josh Susanto wrote:

Thanks to all who have responded.

The (next) short term goal is to be able to produce a 16-prim object with a continuous image of 4096x4096 on one face.

The prims I'm showing are normal box prims, each with a single texture cropped out from a 2048 image.

The build tool says they are perfectly positioned and correctly textured.

I tried both kinds of texture mapping, turned full bright on and off, etc., etc.

Could this be a compression problem?

It's going to be a shame if there's just no way to make this work, because I can produce textures like that at 4096 or larger pretty easily. I don't have some kind of fractal plugin, but I find that explode in Irfanview does something similar if I keep sizing the dimensions up double before I explode.

Start with a 2x2 image with random pixel colors if you're curious.

---

 

I guess you missed my post.  No, it's not a compression problem, and it's got nothing to do with planar vs. standard mapping, or with lighting.  It's an issue of clamping vs. tiling.  SL does not do the former, only the latter.  So there's no way to do what you're trying to do without having the seams be visible.

[Ceera Murakami]

The problem is that SL attempts to wrap the texture from far edge to far edge. It assumes that ALL textures are seamless ones that will tile to some extent, and not that you might ever want to put a texture exactly as-is on one prim face.

Let's say you have a texture that is 50% white and 50% black, split horizontally. Take that texture and apply it to two prims, one above the other, with the bottom one rotating the texture 180 degrees, so the two black halves touch.

In a perfect rendering situation, the black would be seamless. But in SL, you'll have a two pixel wide white line at the seam. Why? Because it is bleeding a bit of the far (white) edge onto the black edge.

You can minimize this by setting the texture repeat to 99% in the build tools. The texture won't match perfectly, but the far edge bleed will be gone. If you use a script to set the texture repeats, you might manage to set the repeats to 99.8%, and make it almost truly seamless.

 

What Chosen and the others said is right, however. There are extremely few valid reasons to split a mega-huge texture into 1024 x 1024 pieces and display it across multiple prims. It's a waste of graphic resources.

[Drongle McMahon]

Ugh! I never knew about that bleeding artefact. It's horrible. Did anyone ever make a jira asking for a toggle to turn the tiling off (repeat edge pixels instead)?

Anyway, what follows is irrelevant now, as Josh says they were not sculpts, but I took the trouble anyway, so....

To illustrate the use of 4x4 quad sculpties, I made two maps, one without (left) and one with (right) the vertex collapsing required to stop the shading artefact. At the top is a collection of four of each. The maps are shhown 16x. These have only 32 triangles. So they are more triangle-efficient than the box prim for making a flat plane textured on both sides. (That's really only true if they are so big that they never switch to low LOD. In fact the 4x4 sculpty bstays 4x4, and 32 triangles, for all LODs, while the box prim goes 108 -> 48 -> 12. So if the third LOD is reached, the box is better.)

[Chosen Few]

Am I invisible today?    I explain the problem twice, but nobody responds either time.  It's not until the lovely sweet Ceera comes along to explain it a third time that all of a sudden people get it.  Ooh am I feeling the love.

 

Anyway, Drongle, to answer your question, I don't think there ever has been a Jira on this subject.  I've been aware of the issue for as long as I can remember, but for some reason it never even occurred to me to request texure clamping as a feature.  I guess I just never considered it to be all that important.

I would imagine it would not be difficult to implement, if anyone does find it important enough to request it.

[Drongle McMahon]

Sorry. I'm just lazy. I did notice the replication, but just reached for the nearer to reply.

[Kwakkelde Kwak]

Need a hug Chosen? You can have one..YES YOU WERE RIGHT..... THAT WAS THE PROBLEM!

 

As insightful and complete your answers often are, we, the rest of the SL forum dwellers, do not stare at the screen to wait for any of them to pop:)

EDIT..well crap sometimes I do...

[Josh Susanto]

Sorry, Chosen. 

Your message hadn't come up yet when I started my response to the earlier messages.

I am very impressed with the amount of thought that you have all put in on this matter.

Thanks to all, and especially to Chosen.

I'm going to try again with textures at 0.999.

I understand that most people would consider 4096 or larger to be total overkill, but overkill is subjective.

If I can make an 8192 version of the right kind of photo image, I expect there could be some demand for that, at least as a wall in a sex club or something like that.

Otherwise, I may at least be close to producing oil paintings that look like an oil painting even with the camera slightly closer than the naked eye should be able to focus in RL.

I know it's gimmicky, but the right image for the right client might make it viable. With as many users as SL has, there are plenty of people who want something that other people won't believe until they see it.

At a 31 prim limit, I should be able to produce a framed photo at 6144x5120 than an avatar can carry around attached. Most people don't max out their avatar prim limits as quickly or consistently as they do land prim limits, and not everyone has land, but everyone has an avatar.

[Kwakkelde Kwak]

hmm no time to test it before hitting the hay..but wouldn't it be possible to set texture repeat to .996 (1020/1024) to get rid of the two pixels which bleed....and making that area a "void" .... you'd have to make the 2048 texture slightly smaller ofcourse, but it won't be noticable.... Am I clear? I don't think so:) ...I mean if there are two 1024s next to eachother..the third column from the right of the left texture would line up with the third column of pixels on the right texture...hmm yes that's it...

btw..31 prim limit....eeeh?

[Josh Susanto]

Thanks for participating in this.

I have tried it with 0.999, 0.998, 0.997,0.996

I find I slightly prefer 0.997 over 0.996

0.996 produces a different kind of line, which is somewhat mitigated by leaving the extra 0.001

I think for a texture that has more linear content of its own, this effect might be too subtle to detect on 4096 or larger, provided that the whole object  is in the camera frame.

Where I live I can get close enough to some Picassos and Miros and whatnot (for free) to see things I should think they might have preferred to paint away.

Maybe I can work with this.

Did they kill the 31 prim limit on linked objects? Maybe that happened when I was away from SL for a few months.

It wasn't exactly huge news, was it?

[Kwakkelde Kwak]

There used to be a 27 (I think) prim limit on physical items, this was raised to 31 then 32 to my best knowledge. A linkset can be 255 prims, doestn't matter if it's worn or rezzed. Maybe you once had a 31 prim linkset and a prim too far away so it wouldn't link...or you are confused by the 38 attachable items on an avatar. That's all I can think of from the top of my head.

[Josh Susanto]

I haven't had any reason to think about it since early 2007. 

Linking more than 30 prims at 1024 for a single image might be overkill, even for me, though.

[Kwakkelde Kwak]

Yes but the limit has been 255 since I can remember...that was before 2007... anyway, if you don't need more than 32, don't use them:)

 

And 30 1024 textures all in one worn object?! how immense would that object be? it sounds outrageous to me..a single 1024 will look fine if it fills your entire screen...