Helium Loon
-
Posts
309 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Helium Loon
-
-
Should run pretty smooth on High, possibly even on Ultra settings. Depends on what you consider 'soapy smooth' and the sim and how many avatars are on it......
With an i7 and a GTX 760Ti card, with 16GB of ram, you should be pretty well off. I'd expect FPS rates around 60+ in moderately complex sims, and 40+ on complex ones. Turn on everything, and those drop to 30+ and 40+ respectively. If the number of avatars around gets above 7 or so, it'll start dropping further. Regardless, except really mesh-heavy avatars and objects, I'd expect pretty good performance. Getting it better than that would require spending a lot more on the graphics card.
-
You don't specify the kind of CPU for the system.....but the remaining specs look like it should run SL pretty darn well.
If it's a laptop, the GPU will be a 'mobile', i.e, a GTX 760m, which will have about half to two-thirds the performance of a desktop card.If those are desktop stats, and the CPU is an dual-core or better at at least 2.0GHz speed, you should be great. An i5 or i7 intel cpu, or an amd Athlon-II or Phenom-II cpu should be just fine.
-
Hi Tania. Nice to see another Loon here!
If you can give me a few more details about the basic design of the dresses, I may be able to help out. I can't give a firm timeframe for completion, but a few more details about the general style/shape of the dress ( and how much rigging will be required vs. static mesh attachments ) will help me determine just what I can do for you.
Helium Loon, Inflatable Technologies Inc.
-
Have you ever wondered why most people can't draw or paint worth much? It's really simple. They haven't PRACTICED with the tools in that fashion like artists do. Try drawing a perfect circle freehand. Or a box. Or a triangle. Or even a straight line. Not real easy. But artists practice for hours each day doing those. Ovals, boxes, curves, triangles, shading, highlight, perspective, and more.
After a while, it becomes nigh-reflexive. They don't have to think about how to do it.....they just do it, since the motor memory is there, and they know when to use them. They train themselves to see the shapes and forms around them, and can duplicate them using various media.
It's similar. But few schools teach art that way. It's those who stick with art that do that to GAIN that same level of proficiency that would provide the same kind of training that cursive writing practice does.
(As an aside, I just pulled out a pencil and wrote a couple of sentences on paper in cursive. Had to pause slightly on a couple of letters, and my precision is a little below what it was in college......but I can still do it pretty legibly at normal writing speed. And reading it is easy as pie.....)
-
AveryGriffin wrote:Okay you lost me a bit here. Little kids are the first to grab some crayons and go off scribbling something. If you were to give them a simple line drawing to reproduce set up exactly like those 'trace then write yourself' books with the letters and lines used to teach children how to write their alphabet, wouldn't that effectively be working the same areas of the brain, or am I completely off?And, on that same route, is there anything else children can be taught (that they might actually retain and use later in life) that will teach them the same things you say learning cursive teaches them?
That could work, if you had them repeatedly reproduce the same sets of artwork over and over. But art isn't traditionally taught like that. Repetition is a key part of conditioning responses to become near-reflexive. And if the content isn't fixed, the patterns become to diffuse to work as well in training. It works related areas of the brain, but in different manners.
Art is traditonally taught as a creative exercise. While the motor-skill training involved in handling a pencil, a brush, or conte, or chalk, all utilize slightly different to wildly different motions, and those motions can vary considerably from artwork to artwork, the general purpose of art is to train the two hemispheres of the brain to communicate better, and thus enhance creativity even in typically non-creative tasks.
Penmanship is traditionally taught by rote practice. The characters need to be repeated, consistently, accurately, and correctly connected each time. This is a different mechanism of cognition. Creativity isn't normally involved. Almost strictly a logico-motor response pattern that is conditioned.
As I said, BOTH are important.
(ETA: As for 'something else' that could train the same way......not much comes to mind. The three 'R's have stood the test of time for a reason......First is reading, then writing, then arithmetic. And they're usually taught in that order, since the child first has to learn the patterns, then learns to duplicate the patterns, then begins to ascribe value to the patterns. Yes, technically "Comprehension" should be between writing and arithmetic.....but while it starts there, it continues on (hopefully) throughout life.......)
-
Perrie Juran wrote:When my daughter was in Elementary School, she was struggling a bit with the Multiplication Tables.When I asked her Teacher for some suggestions on what I could do to help her with them she replied, "Don't worry about it. Next year your daughter will be allowed to use a calculator."Some of my response to that statement is not printable on this Forum.
I can honestly say my response would have been:
"No, she won't. Because she's going to learn her multiplication tables, so she doesn't NEED a calculator every time she has to solve a simple aritimetic problem. Until she can, I won't let her use a calculator."
Though my own daughter probably won't have any problems learning them, as both me and her mother sit down and help her with her homework and such quite frequently. We make time for it. That's part of being a good parent.
And the teacher's statement doesn't surprise me in the slightest. Just more evidence that the educational system here isn't interested in actually teaching kids who want to learn. They just want to get as many kids and process them through like an assembly line and mark them 'sufficient' even if they aren't.......so they can get as much federal and state funding as possible.......
It truly saddens me that schools in this day and age have come to this.....
-
Oh, and as an aside....
Typing on a keyboard doesn't train pattern matching nearly as well. The complexity of training a motor response to a pattern (either seen or imagined internally) and either drawing it or pressing a single finger in one of 3 ways? Drawing the characters is much more complex. Learning cursive helps to train motor responses to be much more precise and fluid. Many of the young students I see today can't even print well by hand. They KNOW how the characters look, but they don't have the fine hand motor control that lots of practice writing can give. Cursive and Print both help. But learning and practicing only one helps less than both......
-
AveryGriffin wrote:I'm gonna have to agree with your whole post, besides this point here:Helium Loon wrote:1) The cerebrum part of the brain is a pattern matching machine. It's a BIG part of how our higher brain functions work....by recognizing and matching patterns. Learning (and using) cursive helps train that part of our brains to be BETTER at pattern matching. While there IS a standard for cursive, every single writer using it varies their writing of it in small (or sometimes large) ways. By learning cursive, the brain learns not only to recognize the basic patterns, but also develops the flexibility to still match subtle differences.
Don't you think children can be taught this exact same thing by taking art classes (drawing/illustration, not 3D things like clay or metal working, or painting and printmaking since those are different) rather than learning a different way to write? Art can accomplish all this and much more. Only most schools heavily under fund art programs because they 'aren't useful', which is a shame.All the art teachers I've ever hadended up providing most of the supplies out of pocket.Yes, but at different stages. Developmental cognition passes through several stages. Art is typically more a creative, rather than matching process, and while learning the technical aspects of various mediums DOES provide a similar type of training, it isn't usually something that is used nearly as heavily. Artistic processes aren't rote, and many of the mediums used aren't well suited to very young children. In addition, the content is not fixed (with limited variation) like with cursive writing.
They are both important. And they both enhance cerebral development, but in different ways. And while each will benefit the other to some extent, neither trains the other side as well as its own.
-
I have to say I'm appalled at all the support for dropping cursive. A few points to clarify why it's important:
1) The cerebrum part of the brain is a pattern matching machine. It's a BIG part of how our higher brain functions work....by recognizing and matching patterns. Learning (and using) cursive helps train that part of our brains to be BETTER at pattern matching. While there IS a standard for cursive, every single writer using it varies their writing of it in small (or sometimes large) ways. By learning cursive, the brain learns not only to recognize the basic patterns, but also develops the flexibility to still match subtle differences.
2) History and tradition. As another noted, if you can't read cursive, reading many historical documents is closed to you. Old letters your parents, grandparents, ancestors might have written? Unreadable if you don't know cursive. The US Constitution (for americans) is written in cursivve, as is the US Declaration of Independence. Old records? Filled with cursive notes and signatures.
I'm even more appalled by those who are pleased to see it being dropped because 'it was too hard' or 'I know print, why should I have to learn another writing style?' Think cursive it hard? Ask Japanese students about what THEY have to learn, writing-wise. TWO basic sets (hiragana & katakana), and then over 2000 pictograms (kanji) just for basic literacy. And they have to use those EVERY DAY. And it's more complex than that, since each kanji can have anywhere from 2 to 10 different ways it can be read.....
Education in the US is rapidly becoming a joke. The whole 'No Child Left Behind' movement, along with litiginous parents who don't bother doing much (if any) parenting is killing the educational system here. Parents don't want to accept that BY DEFINITION, half of the kids (including theirs) are BELOW AVERAGE intelligence. Let's face it.....as the late George Carlin so eloquently and accurately assessed: "Kids are like any other group of people....a few winners, a whole lot of losers."
Every child is not a 'special snowflake.' Every child is not smart, clever, cute, beautiful, witty, or any number of other superlatives. Some are. But most, again by definition, are average. And, like any other bell-curve population, there are a few geniuses as well as some real idiots. Accept it. Teach them that with hard work and application, they can still achieve success. We need to quit filling their heads with this nonsense so that when they do get out in the real world they aren't completely unprepared to deal with it. Too many are already out there, with an entitlement attitude that is only made worse by this kind of nonsense. Success is earned, not deserved......
Cursive was, and is, a pain to learn. So was memorizing multiplication tables, learning fractions, and memorizing spelling. Should we drop those too? After all, we've got spell-checkers, calculators, and more now.......
Just becuase we have easier ways to do things thanks to technology doesn't mean a prior method loses value.
(Edited typos)
-
My first thoughts upon watching this were:
"If they added a few dozen lens flares, I'd sware it was a new J.J. Abrams flick...."
Can't even tell it's a comedy......Though hopefully The Black Beast of AUUGHHHHH will smite them verily for such a pooftah-esque trailer......
-
You set it in your nVidia control panel. It's the "Wait for Vertical Sync" parameter.
When Set to "On", the card will wait for the vertical sync time to elapse before it allows the screen buffer to be 'flipped' into view. This means that the card cannot exceed the Vertical Refresh rate of the monitor. This does NOT limit drawing commands to that rate, however, only the change between screens buffers that updates what is being shown. The purpose is to reduce 'tearing' which happens when the card swaps buffers so fast that in the middle of updating the screen, the next screen is finished, and it flips between screen buffers before the monitor has finished drawing the screen.....resulting in part of the rendered screen being from one frame, and the other part being from another. Setting this parameter to 'ON' prevents that. It's to keep the card from rendering faster than the monitor can keep up.
If you want to reduce the load on the GPU, this won't help. Use the MaxFPS option in the viewer.
-
It's possible, depending on the objects involved, for it to be rezzed on a different parcel, and extend into yours. If the root prim (or even just the object center, if it's mesh) to be in one position, and the rest of the actual geometry to be quite a ways away. Which means the server would consider it to be 'rezzed' on their land, even though all or some of the actual geometry is in your airspace.
-
I have to agree with many of the others here.....don't give up, just step back. It took several months before I had several friends in SL that I could actually sit and just chat with or do things with. But if you are determined, good luck!
My guess? L$4000
-
Whenever you TP to a new location, all the objects there (avatars, rezzed prims, sounds, textures on prims, etc.) have to be updated in your viewer. The viewer DOES cache stuff locally, but it still has to check. That means communication messages from the server to your viewer. And if anything is there that isn't in the cache (or the cached version is too old) has to be downloaded to your viewer as well. Those downloads take up bandwidth as well.
Now, after everything downloads, for EVERY active object, the server has to send updates periodically to the viewers that are connected. So in a crowded area, there are more avatars, which mean more updates every second. Lots of server-side animation of objects also increases the number of update messages per second. If an avatar changes its animation (from idle to walk, or turning, or whatever) the server has to send an update to let your viewer know it happened. When someone chats, that's another message from the server....more bandwidth. But unless there is a LOT of chat going on, chat is pretty negligible for bandwidth......
So, the more active objects/avatars, the more bandwidth.
Now, if you are getting REALLY LOW bandwidth numbers, that could indicate that your connection is having problems, or that the server is so bogged down it can't send out everything as often as it should.
-
Madelaine McMasters wrote:Mono is a bytecode interpreter and I've no idea what the virtual machine looks like, nor how the compiler handles the situation we're discussing. This seems like something a curious person with excess spare time could test ;-)
Sorry, no spare time here.....busy writing stuff under WinCE at work.....*ugh*.....
Madelaine McMasters wrote:I'm still not sure there's any overhead for putting a simple statement inside a block by itself. If that sole statement is a function call, it'll need the same stack frame whether in a block or not. Since we're talking about bracketing simple statements, are there examples of them that would have local variables?The compilers that I used in my embedded work (GCC derivatives) would generate the same code for a simple statement, regardless if it was in brackets or not. If allowed, they could also inline functions, unroll loops and do all sorts of things that taxed my ability to recognize my algorithm in the resulting assembly language and made it nearly impossible to trace execution with my logic analyzer, or to single step through non-existent loops with the debugger.
Oh, I agree about modern compilers.....said so above. They optimize heavily these days. But bytecode interpreters and compilers for Mono? Not so sure about those. And we BOTH know how lazy programmers can be.......
-
Any user function calls within a block would also require a new thunk, since the return address needs to place properly in the execution stack (so things unwind properly.) So unless the block contains NO references to local variables or global functions (in Mono/LSL, in C/C++ and other languages it gets even more complicated) then the block contents wouldn't require a thunk. Not sure if built-in functions would also require it.....
Analyzing that for a large block could get quite messy. I'd have to actually look at the Mono compiler code to see how it handles this...... Not sure if it would bother analyzing code that in-depth. Obviously, modern high-level language compilers do a LOT of optimizing and analyzing.....but I doubt Mono does more than cursory optimization.
-
Hmm. That seems potentially hazardous. Jumping to a label within a scoped block (from outside that block) would present all kinds of problems if they are scoped at the event/global level. Jumping out wouldn't be as big a deal.
If Mono/LSL does this, I can't imagine the level of overhead involved in re-establishing the thunks/scopes involved if the label existed inside nested scopes, but was jumped to from outside them........that's got to be a nasty hit.
-
Okay. This isn't a complete script. There aren't any defined values for the sub_menu list, and you moved the code you asked to be altered outside of any events. And the whole set of values for reds,pinks,violets,dk_blues,lt_blues,etc.....are never defined anywhere. This wouldn't have worked before the changes I suggested.
If you need a custom color-changer script, just let me know, I'll be happy to code one up for your particular purposes (complete with full comments for learning purposes) for a reasonable fee. It would take less than an hour to write it up, so I can be flexible on cost.
-
Unlike all the others, I will actually speak to the efficiency/compiler consequences of using a 'block' or compound statement instead of a simple one (when it will suffice.)
Do a little research on compiler theory. One will find that whenever a 'block' opener is found, the compiler introduces a new 'thunk' or stack frame. This is why variables defined within such a block have scope limited to that block. It introduces a new stack, and new address references (you can add a label to a 'block', for unconditional branches, etc.)
However, a simple statement does not require the creation of a new 'thunk'. Therefore, from an efficiency/speed viewpoint, using blocks in an IF or ELSE clause when not needed actually degrades the performance/efficiency of the code. Creating a new 'thunk' requires additional memory, and has setup time.
Now, most modern language compilers optimize this anyway.....if only one statement is found within the braces, it will automatically simplify it to the non-enclosed version for compilation. I'm not certain whether or not Mono does this or not.
So, for myself, I will continue to use BOTH formats, as appropriate. When doing initial coding, I will use the braces everywhere.....then once the function/event/etc is debugged and working, any single-statement blocks will be pulled out of those enclosing braces.
-
From the description, they are wanting to trigger something in a REMOTE prim. Possibly same sim, possibly not.
If the prims are in the same sim, set up a llRegionSayTo() call and a matching Listen() event handler in the pair. If they are NOT in the same sim, you'll be limited to either using http server/client in SL (using the llRequestURL(), llHTTPRequest(), llHTTPResponse(), and http_request() event methods.)
-
list primsToColor = [3,4,9]; // list containing the prim numbers you want to colorif (index != -1) { vector color_vector = llList2Vector(sub_menu, index+1); if (llGetLinkNumber() == 1) llSetLinkColor(LINK_SET, color_vector, ALL_SIDES); //If it's root prim, do whole set else { integer i; for(i=0; i < llGetListLength(primsToColor); i++) llSetLinkColor(llList2Integer(primsToColor,i),color_vector, ALL_SIDES); //otherwise, do prims in list } . . .}I think that should do it for you.
-
Just looking at the pictures you included, some of those parts are patches, not triangles meshes. You may need to convert them to regular mesh triangles. That would also explain the difference in triangle counts.
-
In your third llSay() you are using llListFindList()....and it's correctly returning the index of the (not) found item (since it isn't a list being passed in for person.)
Try
llSay(0, "the first value is " + llList2String(participants, llListFindList(participants,[person])));
-
Well, I haven't looked at the actual code involved, but the 'specular exponent' is a term in several shading algorithms, and it refers to an element that controls the 'tightness' of specular highlighting. A low exponent spreads the specular highlights out, making the object appear less 'glossy', while higher exponents cause the highlight to become very tight and narrow, resulting in a very shiny or metallic specular highlight.
Someone more familiar with how SL is implementing this can probably give a more specific answer, though....
(eta: I looked at the linked page, and yes, this is what this parameter does. It causes the specular highlight to spread out at low values, and tighten and narrow at higher values.)
Facebook
Instagram
Twitter
YouTube
Flickr
Low land impact seems to demand a single script
in LSL Scripting
Posted
Once again, it isn't one or the other. It's when you take things to extremes that the system will perform badly.
Steph is quite right.....1 bad script is worse than 20 well-designed ones.
But, 3 decent scripts can out-perform 20 well-designed ones, and keep things more manageable.
Compartmentalization is a good thing, but not taken to extremes. Do it when it is NEEDED, not just because you can. Functions in your script are good IF they are well written, and they are called from multiple places in the script. Having a function JUST to refactor (and it's only called from one or two places) is bad. Just inline in those cases, unless you are close to stack-heap collision hell.
Think about your code. It's easy to just start writing it, but if you actually take a few minutes to design first, then implement, it can make a world of difference. Write functions for simplicity, then inline them when they aren't called from more than 2 places (and the funtion itself is fairly simple.)