SLUniverse Forums

Joshua Nightshade

No, higher than 512x512 on anything but epically huge signs is completely and insanely insensitive.

And 512x512 should only be used on prims that need it too. If you're going to put a 512x texture on a prim that's .05x.05 then fuck you kindly.

Verkin Raven

I agree, and I extend my "fuck you" to the asshole developers who stuff their work with inefficient waste just so they can spew stats about having a superior product.

I fucking spent hours tweaking the boat's wake effects so they looked pretty but efficient, had the counter going and came up with a balance, but people these days seem to develop wakes with particles that last too long and spew at too high a rate to boot.

Oh, and don't get me started on the people who make sculpty shapes which are EXACTLY LIKE PRIMS.

prinţesă nină

i will frequently use 1024's. i can load 4-8 'seperate' textures on the 1024 and use texture offsets when texturing the prim.

Drake Nishi

Thanks for pointing out that Jira entry, WarKirby. Voted.

Khamon

This is an intelligent use of large textures if it means texturing the entire object with only one file rather than eight smaller ones.

__________________
Please Visit Our Gardens and Our Website

BEARintheMorning

/me makes a note of that tip if he ever starts building again...

__________________
*Something witty here.

LoganBauer

Why the hell are you persecuting my micro-prim book collection?!? YOU CAN'T READ THE TEXT if they are 256x256!!!!!

(no, I don't really have a micro-prim book collection, I'm just being contradictory.)

__________________

Thunderclap

People have tried. That is why we get Direct X. Oh and Vista orginally wasn't going to support Open GL until most everyone gripped about that and so. Its now supported.

Shyotl

Yeah... No.

It's a limitation of the z-buffer, not really the API.

Alpha Blending - OpenGL.org
The underlying reason for this 'bug' is described, and potential 'workarounds' are listed.

The workarounds for this problem are:
A: CPU Expensive
B: GPU Expensive
C: Hardware limited

About the only thing Direct-x brings to the table that is at all different from opengl, in this regard, is...
Humus - 3D - Stencil Routed A-Buffer
which has hefty hardware requirements, and has considerable limitations of its own. It's simply an alternative method of depth peeling. Also, it came with dx-10.

That said, I wouldn't be surprised if an opengl extension came out, if it doesn't already exist, that would do the exact same as the above new direct-x method. So, yeah.

Directx ain't the cure. Sorry.


Anyhow, back to the topic.
Sculpted textures do actually have priority over normal textures, at a fundamental level. This might, however, be negated by them having a fixed (hardcoded) 'view area' value(since the textures aren't ever truly rendered). This problem is also further compounded by LL failing to boost the sculpt textures priority when an object is selected/mouse-hovered/focused-- the face textures are boosted in priority, just not the sculpty texture. I'm contemplating submitting a patch for the last issue, but it's trivial and obvious enough that it shouldn't be needed... LL just needs to notice this flaw *shrugs*.