Kwakkelde Kwak

It's near impossible to give a step-by-step on making a mesh object for SL. That's like making a step-by-step on raising a child. First of all, what kind of DAE exporter are you using?

That's one way of nicely asking for help.... In 3ds max, select the objects faces and look in surface properties in the edit menu on the right. If every different SL face shows you a different texture ID, the model is fine in 3ds and I suspect the exporter. Your 3ds max and exporter should be fine, assuming you are using the autodesk collada, not opencollada.

That sounds very interesting, hadn't I given up on sculpt building altogether with mesh here... Did you ever try to color 3/4 of the map the same way? If so, what pixel out of the 4 is assigned to the sculpt vertice?

Drongle McMahon wrote: In the case of flat space, where vertices are not contributing to the shape, that is true. They are wasteful. For sculpties they may be necessary to get the intended stretching of a texture. For the equivalent mesh, they can be removed because the texture stretching can be controlled by varying the UV mapping. As far as data download is concerned, the basic data per vertex is much less for a sculpty (24 bits) than for a mesh (at least 128 bits, multiplied up for sharp edges, plus the triangle lists indexing them). Both are compressed and the compression is very dependent on details. I didn't mean vertices not contributing to the shape, yet in the middle of a surface. I ment the collapsed ones. I am guessing SL sends around the sculpt map data, all of it, between servers and viewer, rather than the object to be rendred by the GPU. But in this case it's even easier to remove them when converted to mesh. Thanks for explaining the part on rendering...

It works fine for me, maybe you aren't looking in the correct folder, especially since you're using different viewers. Just try a search on the "new archetype.xml" on your local drive.

Darkie Minotaur wrote: llShout(llList2String(Speach,speach)); You forgot the channel aswell:) To put it into human wording... the "speach" set at 0 will always call the first item on the list. You need to either change the integer on every click like Darkie described, so every time it will shout the next, or dump the entire list to a string, not sure which one you are after. hmm edit. didn't read the title of the thread. If you want a random pick from the list, use llFrand to determine the integer.

No payment info, no mesh, it's as simple as that. My guess is paypal would work for most countries, I use it, without any physical or virtual credit or debit card.

Josh Susanto wrote: OR, I can just become better at things like remembering the interior angles of complex geometric solids. Changing a single element on a uniform object like that will force you to change everything to keep it uniform. There is no point in remembering anything. Josh Susanto wrote: The sad part is that there doesn't currently seem to be any data savings to running a sim in monochrome. Just being able to go there as an automatically decolorized AV in a decolorized space would be interesting. I recently read you can now upload 8 bit textures. I'm guessing SL turns them into 24 bit ones though. If they stay 8 bit, you can save data by using monochrome textures, otherwise you are right. Josh Susanto wrote: NOW you've hurt my feelings. Get over it:) Josh Susanto wrote: Not always for the best reasons, though. My SLM listings say "better than mesh" simply because more people can still see sculpts. It's opportunistic subjectivism. I wasn't referring to your listings. Sculpts can be preferred when you want animated objects, although I'd rather have rigged mesh without the need of an avatar to attach it to. Also when making huge items sculpts can be preferred. I know this is not fair render/upload/primcostwise. What the best reasons are is rather subjective, althoug I am in agreement with you on this point. Josh Susanto wrote: I can probably be a lot more selective than SL's sculpt rendering system happens to be about which verts should render and which ones are a waste of data. I am pretty sure you can be yes. Making your own LODs can really make a difference, both in looks and datause. This is really a win-win, well unless you haev little time to spare to do it, then it's a win-win-lose.... Josh Susanto wrote: > As Chosen would say: A sculpt is a sculpt is a sculpt. Except when it's mesh. >Whether it's 64x64, 128x128 or 1024x1024, the number of triangles on your screen would be the same. Except that I have produced my sculpts at higher resolution, seen them rendered at higher resolution outside of SL, and maintained the same higher level of resolution in the data I have loaded to SL, even if SL has no use for most of it. Moreover, I have imported with the idea of later export in mind. >As I said above, changing to mesh won't save you anything, not renderwise anyway. I don't know if they would be transferred between servers and viewers any slower or faster. Understood. No exceptions here. A sculpt is a (stitched) plane with slightly more than 2000 faces. Changing the resolution doesn't change the SL object (unless you make it too big and lose the lossless...). Changing to mesh without welding or deleting any vertices won't change te SL object. As soon as you do the latter, you are no longer working on a sculpt. I thought you understood, but going by your "exceptions" I am starting to think you are rather taking my word for it than really understanding it. Josh Susanto wrote: Yes. The tricky part is going to be removing the correct ones by some means that doesn't take hours per item. That's why I've asked about some possible function that removes data heirarchically in inverse correlation to how much curvature will be lost in the process. Yes it can be very timeconsuming by hand (can be, doesn't have to be, all depending on your object and your skills), probably not worth the efford to most people. 3dmax has a function called "MultiRes" which does exactly what you describe: identifying angles then remove as many as you want, starting with the smallest..uhm biggest angle, the flattest anyway. Blender has a function called "Decimate" I think, not sure if it does the exact same thing, but it's similair. If I were you, I'd post a seperate question on the forum. I'm sure a lot of people will skip these long posts. Bear in mind these functions really screw up your UV map.

Josh Susanto wrote: I was thinking more of economies of scale to be produced by tetras variously penetrating each other in order to make multiple floors, walls, and room spaces. The buildings would just have some pointy stuff on the outside. If I understand correctly, a point where 2 interpenetrating tetras intersect can effectively serve as a vert without requiring a vert. Am I wrong? Apart from the fact I'd like to keep calling it an intersection, not "effectively a vert", you are right. But this principle is also the case for any other 3D geometry. You can intersect boxes, spheres, cylinders, anything. A tetrahedron has no advantages over any other shape in this respect. See the shape below, it's constructed out of only four cubes: << I can't seem to post the picture, also ate half my post..grrr Here's the link: polyhedron>> Image from wikipedia Josh Susanto wrote: That's almost entirely due to RL constraints. SL constraints are different. That is, a really data-cheap building in SL could look like a really expensive building in RL. Spending more data in SL to make buildings look they'de be cheaper in RL is one possible aesthetic, I suppose. But it need not be the only one. Some constraints or design challenges are exactly the same in SL and RL. The reason some RL objects need CAD over a simple sketch or even full drawing, is usually the sheer complexity, both in structural integrity and appearance. There is no difference in CADing for SL or RL, that is until the designed object needs to be actually built. My point is building with boxes is faster and easier than with any other shape.Imagine your desk being built out of tetrahedrons. At the same "bounding box" or "extreme dimensions"or however you want to call it, on such a desk you wouldn't be able to fit more than your monitor and keyboard/mouse. I'd like the extra space to place a book, or my pencils, or my scanner, or anything. The usable surface is only half of that of a box at the same overall size.Combining two tetras to get the top of the desk flat and square, which you seem to be suggesting (it's not entirely clear to me), would leave you with a dimensionless hinge where they meet. In SL this wouldn't be an issue, I agree. You however can't push the two tetrahedrons into eachother without losing the square surface. If you stop thinking in prims and start thinking in "least amount of data", you would probably end up with a pyramid upside down, that has 5 vertices and 6 triangles. I know this is effectively the same as joining two tetrahedrons and removing the hidden geometry, but the thinking process behind it makes more sense. You need to ask yourself: "what do I want?" Then you need to build that with as little data as possible. If the answer to the question is: "I want to build with tetrahedrons", you build with those. if the answer is "I want to use as little data to construct something that looks like it could exist in RL", you certainly don't build with tetrahedrons. More data to make something look less expensive? If you want something that looks cheap in SL, I can think of many many examples, if you need to use the extra data to accomplish that, then that is what you do. Josh Susanto wrote: If the point is that I people in SL just don't want houses made out of tetrahedrons, that's probably much more true than untrue. But there are plenty of other building types that might benefit from using less data. Shopping centers, for example, could be produced with more shop spaces at a lower data cost, leaving more data for tenants and other things. Of course, I expect a lot of that will end being done, instead, just with triangles, so there's even less data, although walls and floors will appear to be infinitely thin. I guess that could be considered simply to further anticipate technical developments in RL in which load-bearing structures will be made microscopically thin. That might be further than I want to go, though. As I said above, "using as little dataas possible " should be your starting point then, not "using tetrahedrons". On a sidenote, lots of loadbearing constructions in RL are "microscopically thin". You need to let gravity work in your favour and make good use of the tensile strength of the used material. Think cables... For dividers, think curtains... There's this rather famous challenge where you need to make the highest tower possible with a sheet of A4 paper and a roll of tape (both virtually flat). Sometimes there's the extra challenge of it having to be able to keep the weight of a soda can. You'd be amazed how high it can get. Josh Susanto wrote: I'm pretty sure I see what you're talking about. But the complexity of such shapes tends not to exploit the interpenetration of tetras; it sort of just adds them together because that produces shapes that are more familiar in RL. Now I am confused why you brought up the dome in the first place, I thought it was because that used tetrahedrons, ones that DO NOT intersect. Josh Susanto wrote: Sculpts that waste data have a lot of space on them which is flat or almost flat. I see that with oblongs that have a blank spot at the end. Probably those are the most obvious thing to replace with mesh. The only ones I've made, though, are baked down from 16 cylinders, so they use all the available shape data to produce shape information. I'm still not quite sure on this myself. As far as I know the graphics card only renders visible (normals facing the screen) triangles. The SL render cost for a sculpt is based on the number of vertices though, and in a sculpt, those are virtually set ( There's a very small difference in number of vertices on normal and the different oblong sculpts). I think the rendercost SL will show you, is based on this set number for vertices, not on the number of faces that need to be rendered on screen. (SL rendercost is an estimation, GPU rendercost is real). This would mean the sculpts that have blanks are effectively MORE renderfriendly than ones that use all the pixels. On the other hand, the blank space adds useless data that needs to be sent between servers and viewers and I guess the CPU needs to work harder to turn the sculpt map into something that can be rendered. If anyone can tell me more about this process, please do. Josh Susanto wrote: There's always an upside and a downside. Frankloid eliminated a bunch of interior walls, which was nice. But it also meant that a fire in one part of the house was also in all other parts of the house really quickly. That might not have happened so much if he didn't use so much wood. That and he put the entrances in inconvenientent places for fire crews. More private, yes. But only as long as the building still hasn't burned down. I've never seen one of Fuller's domes collapse, although I've seen some made temporarily by other people being tediously dismantled, since they just don't fall over like the wall of a trailer. Really noisy inside, though. That's an undeniable fact. I think Frank Lloyd used more walls than you will find in most dome structures. Why you didn't see any of the domes collapse, is probably because you've never seen on on fire, which was what I ment. I'd pick a solid wooden structure over a steel one in case of fire anytime. Wood doesn't burn as quickly as you might think. Steel structures, which are usually very slender, have terrible structural behaviour when exposed to fire. This is because of two reasons. First is the material gets really weak when heated, second is it is really easy to heat, this last part again because of two things: moleculair structure and thin profiles, which mean little material for a big surface. Wood is a natural isolator, metal a natural conductor. On top of this, most steel structures work as one big element. Take out one little piece and the entire thing will collapse, wood and brick structures don't behave like this (until one of the walls fall down ofcourse). Take out one wooden beam and the rest will stay in place. (This is not entirely true because most of the time the floors connect the beams:) if you want a real fireproof building, use concrete, without the use of steel reinforcement) btw, I think we better focus on SL, this RL discussion isn't helping a lot of people... Josh Susanto wrote: I was again being a bit facetious. But trailers do seem to be a good balance between efficiency and familiarity. Plus they're modular and portable, so maybe SL could benefit from having more of them, at least as long as there are still no physicalized tornado scripts. I thought everything in SL was easily portable, it's the only place I know where you can put a castle in your backpack. Josh Susanto wrote: Of course. And "I'm worried my house will look too expensive" is a concern I hear all day, every day in SL. What was I thinking? Yes I'm wondering what you ARE thinking. You just said so yourself, low rendercost builds can look expensive and vice versa. Josh Susanto wrote: No. I meant, what is the point of using what appear to be traditional material in SL if they are already used in ways that utterly ignore their RL physical limitations? Why not use something that has no clear correspondence to RL physical limits? If our eyes are really not sure what it is or how it was produced, it stands to seem less implausible than unstudded walls made of infinitely thin brick. If it takes less data, too, so much the better. Well there's a big difference between modelling on a computer and actually building it. The task for a 3D artist is to make something look believable, trigger someones brain to fill in the gaps without making that obvious. Sometimes that means a wall without thickness is no issue. As long as there's no door or window in it and the sides aren't exposed, who will notice? I do like some realism, I don't like 10cm flat floors that span 100 meter, but I seem to be one of few on this matter. If your brain doesn't recognize something (like you just said) there might not even be a reason to fill in gaps. Agreed. Josh Susanto wrote: Mesh domes, due to curvature, would seem to be going in the opposite direction from the tetra idea. OTOH, the more boxes you don't use because you're using tetras, the more data you'll be able to use for domes. There seems to be some RL/SL confusion on my part or on yours... Anyway, a dome as you used as example earlier is made out of tetrahedrons in the first place...just a whole lot of them. And as I said in an earlier post, any curved double sided plane can be constructed out of tetrahedrons. (if you want some thickness on it, otherwise you can use triangles) Josh Susanto wrote: They won't connect very will if I can´t just push them into each other arbitrarily and leave them there, no. Why would I be unable to do that with mesh tetras? Again..RL/SL confusion.... in SL you ofcourse can.

This issue has got nothing to do with RLV and as has been said before, the phoenix options won't help at all. Revoke on sit or stand will revoke the permissions granted by the object you sit on I suspect, I don't see how that would ever communicate with a script owned by someone who isn't around. The object or script causing the forced animations works by dialog, so the only way to prevent it is not accepting hugs or kisses or whatever. Once granted, the permissions will stay until the script is reset.

It's pretty easy to check in the about land options...it will show you if Governor is now the owner of the land...

Are you talking about landrights or about estate rights? From what I read about resetting and all you mean estate rights. Ofcourse you don't get those on mainland. Imagine all the owners of land on your sim being able to ban people from the sim or return objects or reset the sim whenever they feel like it. No idea how many owners your particular sim has, but I wouldn't be surprized if there were over 20. That would be fun. I don't think there are enough estate manager slots available for all of them. Anyway, as most people suggested, use the live chat or if you don't want to do that for some reason, file a ticket. In 2008 the sim I own a small plot on on mainland (well my business partner), had some serious issues and LL would reset rather quickly after a ticket, time after time. Live would ofcourse be faster, but at the time I had no premium account.

// Target Particle Emission Demokey TARGET;string myState = "off";myParticles() { string TEXTURE = ""; float AGE = 15; float RATE = .1; integer COUNT = 1; vector ACCEL = < 0,0,0 >; float SPEED_MIN = 4; float SPEED_MAX = 4; vector START_SCALE = < .1, .1, 0 >; vector END_SCALE = < .1, .1, 0 >; vector START_COLOR = < 1, 0, 0 >; vector END_COLOR = < 0, 1, 0 >; float START_ALPHA = 1; // 1.00 float END_ALPHA = 1; integer INTERP_COLOR = TRUE; integer INTERP_SCALE = TRUE; integer EMISSIVE = TRUE; integer PATTERN = PSYS_SRC_PATTERN_ANGLE_CONE; float RADIUS = 1; float ANGLE_BEGIN = PI/8; float ANGLE_END = 0.0; vector OMEGA = < 0.0, 0.0, 0.00 >; float LIFE = 0; integer FOLLOW_src=FALSE; integer FOLLOW_VELOCITY = TRUE; integer WIND = FALSE; integer BOUNCE = FALSE; integer TARGET_LINEAR = FALSE; integer TARGET_POS = TRUE; //key TARGET = llGetKey(); list particle_parameters = [ PSYS_PART_FLAGS, ( PSYS_PART_EMISSIVE_MASK | //PSYS_PART_BOUNCE_MASK | PSYS_PART_INTERP_COLOR_MASK | PSYS_PART_INTERP_SCALE_MASK | //PSYS_PART_WIND_MASK | PSYS_PART_FOLLOW_SRC_MASK | PSYS_PART_TARGET_LINEAR_MASK | PSYS_PART_TARGET_POS_MASK | //PSYS_PART_FOLLOW_VELOCITY_MASK | PSYS_PART_TARGET_POS_MASK ), PSYS_PART_START_COLOR, START_COLOR, PSYS_PART_END_COLOR, END_COLOR, PSYS_PART_START_ALPHA, START_ALPHA, PSYS_PART_END_ALPHA, END_ALPHA, PSYS_PART_START_SCALE, START_SCALE, PSYS_PART_END_SCALE, END_SCALE, PSYS_SRC_PATTERN, PATTERN, PSYS_SRC_BURST_PART_COUNT, COUNT, PSYS_SRC_BURST_RATE, RATE, PSYS_PART_MAX_AGE, AGE, PSYS_SRC_ACCEL, ACCEL, PSYS_SRC_BURST_RADIUS, RADIUS, PSYS_SRC_BURST_SPEED_MIN, SPEED_MIN, PSYS_SRC_BURST_SPEED_MAX, SPEED_MAX, PSYS_SRC_TARGET_KEY, TARGET, PSYS_SRC_ANGLE_BEGIN, ANGLE_BEGIN, PSYS_SRC_ANGLE_END, ANGLE_END, //PSYS_SRC_INNERANGLE, INNERANGLE, //PSYS_SRC_OUTERANGLE, OUTERANGLE, PSYS_SRC_OMEGA, OMEGA, PSYS_SRC_MAX_AGE, LIFE, PSYS_SRC_TEXTURE, TEXTURE ]; llParticleSystem( particle_parameters ); // Turns on the particle hose! if ( (AGE/RATE)*COUNT > 4096) { llOwnerSay( "Your emitter creates too many particles!" + "Please decrease AGE and COUNT and/or increase RATE." + "Give a hoot, don't pollute!"); }}default{ on_rez(integer param){ llResetScript(); } state_entry() { //llSleep(2); myState="on"; integer Counter; for(Counter = llGetNumberOfPrims(); Counter > 0; Counter--){ if(llGetLinkName(Counter) == "BeamTarget"){ TARGET = llGetLinkKey(Counter); Counter = 0; } myParticles(); } } touch_start( integer num_detected ){ if(myState=="on"){ myState="off"; llParticleSystem([]); llOwnerSay("Off"); } else { myState="on"; myParticles(); llOwnerSay("On"); } }} Ok, I hope you're not offended by me making the script, I'm sure you're very capable of doing it yourself with all the info given, but this seems to work fine. Name the linked target prim "BeamTarget", put this script in the main prim and you're good to go. I didn't optimize all the settings, so it can be improved I think, but it looks pretty solid at 150 particles.

Madelaine McMasters wrote: I wouldn't think you'd generally want a firing rate that's faster than a decent frame rate, as that bogs down the viewer without creating anything additional for you to see. A 0.01s emission rate would just emit multiple sets of particles into the same rendered frame. I don't think I've ever used a rate faster than 0.1s. Maybe you'd want that to get a good looking trail of particles emitted from an object moving at high velocity, so the emission points of particles emitted within the same frame were different. That's the only reason I can think of to have an emission rate like 0.01s. Yes I ment the 0.01 as an insane example where you'd still have less particles on screen, 500 rather than 1000. It was not an example on how to make a good beam, I understand I wasn't very clear. Madelaine McMasters wrote: If it's an arc or spherical section, the particles in the burst will be emitted randomly along the curve/surface and so burst count does indeed make a difference in the look. I figured with a solid beam one would go for a point emitter. Ofcourse you can use a wider spread, but you could also go with a bigger particle.

There is also something called Lumberjack. I'm sure these tools are helpful, but they can never compete with programs like blender, maya or 3dmax or any other program giving you full control.

I'm glad to see you solved it, can you post what caused and what fixed your issue, so others can avoid it?

Josh Susanto wrote: My point is not that everything should be made of them, but that if they're as efficient in mesh as has been suggested to me so far, they may very well be getting underutilized at this point. I think you need to stop thinking in prims and start thinking in mesh. Yes I can't think of a 3D object that uses less data per prim than the tetrahedron. But that doesn't mean it's the most efficient building block, both in use of space and in use of data. You can make a door- and windowless building with 11 planes (2 times 6 minus the underside of the floor), that would be 22 triangles. Those 22 triangles would allow only 5 tetrahedrons. I don't think that would build anything that could be considered a building. Josh Susanto wrote: A large part of that is simply lack of development of their use. The last 10 years have shown an explosion of building designs that might have been considered impossible without computer modeling. Yes things are possible now that weren't possible before. CAD helped a lot with that. Still, look out the window and tell me how many of the buildings you see are made out of box like components, then count the number of tetrahedron based builds. My guess is you are looking at a 100% to 0% difference. Building techniques like this can be compared with the cast iron constructions from the 18th, 19th and 20th century. They were used for big constructions where their specific characteristics suited their function better than brick and wood. However, I can't think of any major use in dwellings from the top of my head. Yes cast iron was used in some, but always used the way a wooden column or beam would have been used. New material yes, new way of construction, no. Part of the reason for this is the stubborn nature of the building industry, more important is the fact the technique simply doesn't suit normal housing. As for SL, again I would say stop thinking in prims, start thinking mesh. Any curved surface made on a computer is kind of built out of tetrahedrons, though less uniform as in the dome example you gave. Any quad on the outer surface of a double bent plane is two triangles. if you divide the quad the other way on the inside...what do we have? tetrahedrons... Josh Susanto wrote: Again, partly due to lack of adequate development of the pertinent materials and applications. But the cost in mesh in SL should actually be a lot lower than for other components, which would seem to turn the component cost hierarchy more-or-less on its head, at least virtually. You can't save a lot of data on an SL box. You can save a lot of data on a sphere or torus. You can save some data on a cylinder, you can save a lot of data on sculpts. Using mesh isn't more efficient just because it's mesh. It can be more efficient because you have full control over the objects. Start making 48 sided cylinders and you would be better off with a standard prim, well cost wise ofcourse, not visually. (I take it you ment rendering cost not prim cost.) If you ment primcost, I agree, but that would mean most prims would become obsolete and one of the nice things about SL in my opinion is the fact anyone can fairly build something nice quickly, without having access to or understanding of 3rd party 3D software. Josh Susanto wrote: Bucky Fuller's domes are noisier inside than Frankloid's, but they also don't burn down as easily. There are always trade-offs, and there's practically always some kind of buyer for anything truly innovative. Fire hazards are mostly due to the interior, metal structures won't burn under normal circumstances no, but they will collapse rather wuickly, which can be a lot more dangerous. Josh Susanto wrote: I suppose if we're supposed to apply all the same standards in SL as in RL, maybe I should stick to designing double-wide trailers? I don't think they are the norm where most people live. In SL you should build what you want to build though, whether it looks medieval, comtemporary or alien and whether it is out of boxes or tetrahedrons. Josh Susanto wrote: I mean that we can push a prim into another prim to any depth from any angle and just leave it there. I haven't seen that done with prefabricated concrete components. There are a bunch of other things that can't be as literally done with RL construction materials because they will just plain break and fall off. What are the tensile limits of mesh? For space and underwater architecture, especially, I should think mesh tetras off something plausible in terms of large polymer prefab components that could some day be produced in RL. No? Those prefab components are relatively expensive in RL. Imagine all the molds needed. Every build would need new ones, opposed to the normal which can be used over and over (and over). Tensile limits of mesh? I guess you mean RL mesh. far greater than any box like object ofcourse, compared to the amount of material used. There's a lot of development in materials, so it will only become greater, this doesn't change the fact the entire technique is pretty much useless for normal construction. Only stronger shape I can think of is a solid dome, which is even less flexible in use than the mesh. And guess where the dome is used? in space...and under water:) The whole thing with anything that's not a box is that they won't connect very well. On a flat surface you can have building blocks in repeated uniform triangles, squares or hexagons. In 3D space this is not the case, hence the need for computers and production techniques to make everything fit nicely, using various shapes. Josh Susanto wrote: My wife will see you in Mallworld. Meanwhile, I think we can do even better by making a quasi-monochrome hieroglyphic version in grainy sepiatone. I might add one male character, though. A Rudolph Nureyev avatar from Afternoon of a Faun. I actually once considered making a monochrome sim. Together with the cartoonlike possibilities Loki and others have shown on the forums and some Sin City color effects and atmosphere, that could look amazing. Josh Susanto wrote: I'm a little bit uncomfortable with that because it would create a kind of competitive advantage for the grandfathered content. That might me a lot of extra money for me, yes, but that doesn't mean it's the right thing to do for the total market from the standpoint of sincere capitalism. Capitalism, blah! Besides, as you said yourself in some cases the sculpt is preferred over the mesh. Especially since we can't make meshes bigger than 64 meters. It's not ALL about render efficiency. Advantages for older things are part of SL anyway, I can live with that. Megaprims that can't be created any longer, higher stipends for old premium accounts, lower tiers if I'm not mistaken.... it will always be here. Josh Susanto wrote: Aside from tetrhedrons, one of the first things I want to start doing with mesh is just putting mesh version of my stuff on the contents tabs of my sculpt products, so users are ready with it any time and don't necessarily have to buy something else in order to go meshy. If you change your items to mesh without changing any of the geometry, you gain nothing. The wireframe will be the same, so will the rendering cost. The only result you will see is probably higher prim cost. Josh Susanto wrote: Almost all my sculpt maps are at 128x128, so it's potentially a lot more shape data for people who want it than what they're currently seeing when the sculpts are rezzing as sculpts. A very simple shift to some mesh version could also offer them simpler and less costly shapes under what I now understand are the real data costs. As Chosen would say: A sculpt is a sculpt is a sculpt. Whether it's 64x64, 128x128 or 1024x1024, the number of triangles on your screen would be the same. As I said above, changing to mesh won't save you anything, not renderwise anyway. I don't know if they would be transferred between servers and viewers any slower or faster. You can only save data by removing triangles, which is probably very possible in a lot of your creations. Josh Susanto wrote: They can stand on something else if standing is important at all. They can stand on 2 triangles, for example. I'm not very clear, it's true, on exactly how all the data demands are met in SL. I just know that the ground is not strictly necessary, and that it uses a lot of data. Getting rid of it was just a suggestion, really. What if people want to make their own kind of ground instead? Why should it always be redundant? Interesting idea, I don't think it will catch on though. If you want to save on rendercost for the ground, you can also start building at 2000 meters high and set your landing point there. Not sure if the data would be loaded when entering the sim, but your graphics card wouldn't have to render it. You can also turn off water and ground rendering in the advanced menus, but that's ofcourse only viewer side and can't be forced onto others when entering the sim, nor does it remove the physical ground.

Hmmm, no idea about the follow, that's why I asked:) ... But I really ment 20 at a time, not the amount per second. Min and Max speed are the same, the trajectory is the same, doesn't that mean it wouldn't matter if you create 1 or 50 in theory as far as looks go? If you set the amount to 1 and the rate to .01 you still only use half the particles...500 shown at all time sounds reasonable for one object, well depending on the lentgh of the beam. Btw, I would really go with two prims, one emitter, one target, that way the particles don't cross, I think you can save on the number of them that way. That does require an extra script as far as i can think of though...so it's a tradeoff.

Just out of curiosity... is the "count=20" not very high? ...and can't you let the emitter follow your av rather than the position it was created in globally with the "follow" params?

Josh Susanto wrote: Please do. I don't have the time or patience to get between you and Chosen:) Josh Susanto wrote: Thank you. You're welcome. Josh Susanto wrote: It will build you architectures consistent with current RL engineering constraints. Exactly, and that's what most people in SL are after aswell, something they can recognize. Josh Susanto wrote: If RL construction materials behaved more like prims, I'd expect to see tetras used more already in RL. They're strucurally stronger than boxes. Yes they are stronger, but they are near impossible to design and work with. (In SL even worse than in RL) Production and building costs are on a whole different level than your average concrete wall and floor or drywall construction. They are nice for flashy architecture, not for common building. We've lived in boxes for milennia and we will for some more. It's just the most efficient and cost effective way of building for human use. Btw I don't understand what you mean by "if RL construction materials behaved more like prims". Josh Susanto wrote: What you'll give up by using more tetras is a bit of snugness and familiarity. What you'll gain is more data to apply to intentional contrast elements such as rock, plants, furniture and appliances. Moreover, the tetras may allow even more compelling types of contrasts. I don't quite understand what kind of data you are talking about. Josh Susanto wrote: OTOH, we can save even more data by making one-sided, strictly flat avatars and having them interact on a completely planar sim space. Maybe some kind of all-female shopping mall... in ancient Egypt.... That actually sounds quite interesting:) Josh Susanto wrote: I think that depends on how and when the new rules are implemented. Advanced notices and long adjustment periods are just good customer relations policies in almost any business. But things do have to change sometimes. Most consumers understand that. The other approach I expect will eventually be applied by LL is to make the pertinent changes abruptly without announcing them, but to prepare some kind of semi-plausible contingency explanation about finally having given in to an unstoppable groundswell of customer demand for such changes. They will, again, increase my chocolate ration. A good percentage of all things you see at any time on your SL screen are probably sculpt. LL won't break all that content at once. They might do it in the future, if the sculptpercentage has decreased substantially. So I mean FAR future. What they could do is grandfather existing sculpts and apply the new rules to all new ones uploaded. I'd be all for that, sculpt creation would grind to a halt without breaking any content. People like yourself should be given the time to brush up their modelling skills ofcourse so they can continue their business with mesh instead. Josh Susanto wrote: Unless gradually converted. Especially in-world, for free. Almost everything I've made should be pretty easy to convert already. Converted into what? Same geometry means same rendering cost. Your items might convert well, I looked at some on the marketplace and I'm sure they will. Others won't, like the giant mountains I described. Josh Susanto wrote: And how hard would it be for LL to provide sim owners with a "remove land" function that frees up that data? No land means nothing to stand on...I don't think that will work very well. Besides that, you're comparing apples and pears. The 512 and 1024 mountains are outside of the sim and can't be walked on. They are scenery, not replacement for or addition to ground.

I tried to show the wireframe..but in the latest viewers it doesn't seem to work, neither by hotkey or by menu...what however DOES happen if I click the wireframe option, is the mesh popping right away. Maybe this is a clue, but I haven't got the first idea how to start a JIRA on this...

Madelaine ment the particle itself always faces the screen. What you want is very possible. I think all you need is some extra communication between the two ends of the beam. Something with on_rez or attach to start the communication should work.

I won't get in the way of your general discussion, but do like to comment on your last two questions.... There's more to the rendercost than vertices and faces, but two tetrahedons should be more or less as "expensive" as a single cube yes. Why aren't they used more often then? I'm quite interested why they would be used, I can imagine something like poseballs or invisible scriptcarriers or anything where shape doesn't matter. But usually shape does matter. Boxes will build you walls, floors etc. A tetrahedron will build you ..eh..a tetrahedon. If shape really doesn't matter, you are better off with a single triangle than 3D geometry anyway. And sculpts shouldn't have the extra benefits no, but there are so many around, it would be very unfair to builders like yourself who made and make good use of them, to apply the new rules. Too much existing content would virtually become useless because of the primcost. A good example are the landscaping sculpts which are either 512x512x something or even 1024x1024x something meters. I'm sure it's possible to calculate how much they would have cost as mesh (which have ofcourse a 64 m limit), but I'm very sure they would cost so much nobody would ever use them again.

You can name me by name:) And indeed it was not ment as mocking or to ridicule...just complete surprise. If my comment was insulting in any way, I apologize Josh. btw being stubborn like you are can be good Josh, it allows one to really dig into something once convinced it's the right way. I know, I might be just as stubborn as you, if not worse. But on this thread you finally seem to be at least slighty convinced about the benefits of mesh/blender. Credits to you Chosen, I wouldn't have had the patience!

Good to hear! Maybe the Prim Composer reads the unit setup when you start the program, that's all I can think of after re-reading your first post which says you changed the units correctly...