Jenni Darkwatch

It's the camera cutoff... sometime in the past LL has made a change that moved the render cut-off a fair bit in front of the avi. I've noticed that myself but never found a way to fix it.

True... it's additional work for little direct benefit. I think it's worth it though, so I'll probably add that to my workflow for future scripts. And my own HUD, too (it's free and fullperm - if you want a copy, feel free to holler).

Kwakkelde Kwak wrote: There are a lot of worn and rezzed lag monitors around and I had a question about them. I use some items (not my own) that have a large amount of mono scripts in them, purposely set to mono for faster execution. The memory use, as I understand it, can be anything from 0 to 64k opposed to the set 16k for an LSL script. The lag monitors, again as I understand it, read the full 64k for the monoscripts instead of what they actually use. Using the estate tools I can see I produce little lag (script time anyway, around 0.3 ms usually), yet the monitors always show me as very laggy (in memory I guess). 0.3ms for scripts on an avi is somewhat in the upper range of "acceptable", IMO, considering one frame on a simulator only has 22ms. However, since the simulator throttles scripts first thing it runs into timing problems, I'd consider script time to be fairly irrelevant in most cases (busy venues aside). Unfortunately the way script time works is that it "settles" over time, meaning when an avi TPs in, it's going to be high. Check 5 mins later and the value is more accurate. Memory... yes, that's a problem. Any measure of script memory is going to be skewed for mono scripts, as it is right now. The suggestion about using llSetMemoryLimit()... I really should start using that myself. Even dynamically adjusting memory limits should be fine IF it's not done every second or so. Just IMO, haven't tested it.

We'll just have to agree to disagree on raytracing vs. raster. To me raster is a dead end for various reasons. Doesn't matter though, it's unlikely raster will vanish anytime soon. Too much technology is built on raster.

When I said "beat the pants off" I meant by visual quality, not so much render speed. Hence the first sentence "true if you only consider realtime rendering". I don't have any better info on either chipsets - I've long ago left the 3D graphics industry.

All true, if you only consider realtime rendering. The output of (consumer) GPU rendering is pretty damn crappy though. There's at least two (commercial) hardware render cards that are not triangle based - one uses raytracing (CausticOne), no idea what the other (RayCore) uses. Both beat the pants off any triangle based 3D render. Even so, software rendering is far from obsolete. Look at Hollywoods' computer animated movies. None of them use hardware rendering the way craptastic consumer GPUs do. Raster GPUs are so entrenched that many think they're the best thing since sliced cheese, when in reality they're a dead end.

What permission do I need to set for group members to see a list of scripted objects on the land (with V2/V3 based viewers, the old stuff doesn't have an equivalent IMO and I don't care about ancient viewers either).

For a company, diversification is good. SL will eventually go the way of the dodo bird anyway, considering its tech is _still_ more approproate to the year 2000 than it is for 2011 or 2012.

I need to understand collada in order to write the script.

IIRC the font the viewer uses isn't consistent across viewers, skins or even operating systems. There's plenty of "special" (unicode) characters that simply come across as gibberish to a lot of people. Unfortunately that does include a lot of country specific characters, like accented characters. For groups it's definitely a very bad idea to use anything than regular alphanumerics. If they show up as squares, it's a font problem. If they show up as multi-character gibberish it's an OS or viewer problem.

I second your "Thank You". My personal feeling is that LL has a renewed focus, though it still seems blurry at times. Personally, I'd also like to add one big, major suggestion - even if it's not an easily doable one: Improve sim crossings _or_ offer "megasims" (i.e. 512x512m sims, 1024x1024m sims or somesuch). As it currently stands, driving, flying or boating in SL is a mixed experience. With sim crossings about every 256m, using any "fast" vehicle becomes an exercise in crashing. My suggestion would be to offer megasims. Considering that there's more than one simulator on each physical server, it sounds like a no-brainer to me. Collate mainland sims into megasims, or even just open water sims like Blake Sea to test it.

I'd hardly call 400 people a great success.

Kwakkelde Kwak wrote: I was wondering about all this collada text editing I see in this thread... is that because it's useful or because Blender makes such a mess? To me it sounds like changing pixels on a sculptmap by hand. Don't we have 3D software so we don't have to do all this manual labour? For me it's useful to understand the format, because I largely intend to use computer generated meshes. One example are 3D renderings of a sim or parcel. It'd take forever to do by modeling, it's a snap when I just "scan" it in-world and have a simple PHP script generate the collada file. There's a few other cases for that kind of use as well. And all that just is an excuse for my own curiosity. I like to take (certain) things apart to see how they work.

Best bet? Try and see how they work for you. Just make sure you DO NOT share the same cache location between viewers. Or the same config file, really.

You can use the "Insert Code" block for XML, like this: <polylist count="1" material="BottomFace"> <input offset="0" semantic="VERTEX" source="#cube1-0-Vtx"/> <input offset="1" semantic="NORMAL" source="#cube1-0-Normal"/> <input offset="2" semantic="TEXCOORD" source="#cube1-0-UV"/> <vcount>4</vcount> <p>0 2 22 4 2 29 7 2 6 3 2 1</p></polylist> SL's importer seems to be very selective when it comes to collada I'd dearly love a good collada format explanation myself btw... I can write very simple geometry files by hand, but really nothing more complicated than that. UV maps? Normal maps? Forget it, haven't got that far yet.

I've tried to think about how to do it but can't come up with anything useful. The 256x256 pixel map one can get by querying http://d119xv57hiwi0f.cloudfront.net/map-1-<SIM_X>-<SIM_Y>-objects.jpg is a bit on the low res side and pretty fugly anyway. Does anyone know of a good way to get a more accurate/larger scale map tile? I was thinking of TPing my avi up to height, in the center of the map, then cam straight down and take a screenie. Seems a bit... hackish. Any better way?

Not necessarily. Today, most renderers are triangles. However, there were some oddball render engines around that could indeed handle ngons, as long as they were flat. I'd suspect some render engines even today can handle ngons too, though I don't know of any non-raytracing ones that do. The old DOS AutoCAD renderer had ngon surface rendering. I wouldn't call it realtime though.

I admit I simplified a little. The actual object was of course fully 3D (largely to test what exactly the uploader does). LindaB's post made me wonder just how smart the uploader really is, so I created a collada file by hand with a text editor to add a few edge cases. The shape was essentially a box, with the top side being a 4x4 quad grid and the sides being ngons (but rectangular in shape) and the bottom then being a regular quad. The idea was to see if the uploader really just uses the 1st point of the ngon and traverses from there. Indeed it does, thus producing the odd result. Btw, I do passionately despise the term polygon, even if it's used quite frequently even by me. :matte-motes-evil-invert: It simply is too broad for a in-depth discussion of geometric models. Akin to having a non-planar quad... bad karma, it is.

Kwakkelde Kwak wrote: Normal mapped? in SL? I'm getting a bit dizzy... And ignoring triangle orientation? that really would surprise me. Are you saying SL treats both quads I drew the same as far as shade and light go? I'm not sure I used the term normal mapped correctly. SL definitely does some kind of mapping, to smooth out surfaces. I tried it with a relatively simple example: Create a cylinder with 8 segments, upload it. The edges are hard and quite noticeable, UNLESS you check "Generate Normals" in the uploader. Left image is without checking that box, right is with normals generated at the default 75 degrees. This computer isn't powerful enough to crank up graphics, so I can't tell for sure what kind of shading this enables. It does obviously not add any triangles to the model. Based on the naming of the option I'd guess(!) it automatically generates a normal map. Normal maps included in the collada file seem to be ignored as far as I can tell. Btw, a little testing did actually confirm what others have posted here... letting the uploader auto-generate triangles from ngons is just bad. I've uploaded a rectangular ngon, and the uploader did triangulate it so that the triangles were connected like this: The top "triangles" were essentially a two-dimensional line. Again, based on old knowledge that's not a good thing and a good argument for doing the triangulation or at least quadrangulation by hand before uploading. Of course, things have changed so much that it might just as well be irrelevant with modern GPUs Edited to add: I realized I made one connection too many in that graphic... sorry. Basic principle remains though.

Kwakkelde Kwak wrote: LindaB Helendale wrote: SL mesh uploader triangulates the polygons (specified by <polylist> block) by drawing edges from the first vertex in the list to all other vertices, which is not so good way to do it. A hexagon is triangulated like this Ok, educate me here. The behaviour of lighting on this hexagon would be different from one where the lower triangles would be mirrored horizontally, but I really don't see why this is "not so good". When it's flat I see no disadvantage at all to be honest. LindaB Helendale wrote: Quads are done the same way, so for quads you could let the mesh uploader do it, but not for any polygon with more than four vertices. This is just not true. As both Chosen and I said earlier, the way light hits a quad when bent, is affected by the orientation of the triangles within it. Two quads with the same vertice pulled up, as you can see they are nothing alike. Oke this is getting waaaay geekier than I had thought ~g~ Apologies if I use old, outdated, ancient terminology but... back in the day of software shaders, there was a (fast) way to shade polygons if shading was desired, i.e. to make any surface appear curved even at low triangle count. It was called Gouraud Shading, pretty simple math interpolation really. A better shader was Phong Shading, which I'd guess is what's in use in SL. Based on how the uploader provides a way to allow for the automatic generation of normal maps I'd guess SL has a similar mechanism in place. Forgive me for not verifying the source code. I did however try it with a test object. For all intents and purposes the SL shader seems to ignore triangle orientation _if_ the surface is normal mapped. If not, your distinction is of course correct, though in that case I'd thing the edge is intentionally placed by the person modeling it.

Most definitely not spam. Btw, that low-to-high is an interesting technique. I kinda go the other way around, but I'm also still stuck in the last century when it comes to practical knowledge about 3D renders. Software renders, no room to store different LODs etc.pp. Lots of new things to learn, I'm afraid.

Thank you all very kindly, that cleared up one question. Not having to worry about quad/triangle is nice, though I think as the last step I'll go ahead and tesselate so I can see what the outcome is before uploading.

So I figured christmas is a good time to waste on mesh. Blender is too atrocious for me, and after mucking with a few programs I settled on Wings3D - still a crap proprietary UI, but at least halfway usable. I figured the first thing to try was a simple marker buoy. Uploads fine, 3 LI at normal size (my fault, didn't optimize it). From what I read (and from ancient 3D experience) all surfaces must be quads or triangles. There's the first question... I only knew of triangles as render unit for realtime renders. Wiki says quads are fine too. Should I rather go for triangles when tesselating? Does it make any difference?

Finding _anything_ in SL is a nightmare. Using the marketplace to search is still the easiest way to find anything, unless you know someone who knows someone who happens to know what you're looking for in-world. Same as RL, except it's easier to find things on the better-indexed Intertubes.

Then it could be that the Mac SL client does something different than the PC client and Bell blocks or alters it... what that could be though... without being able to look at the network stream I can't really tell. Maybe one of the Lindens could.