Kwakkelde Kwak

Clover Nowles wrote: My viewer will not open I set the graphics to ulta and then it crashed and now it wont open I tried re installing it and everything. What do you mean by "it won't open"? Does the viewer start at all? If you crashed because you set things to ultra, that is probably a hardware issue on your end. You can set the viewer back to medium or any other setting before logging on. That is if your viewer opens at all of course. Can you post your system specs? (CPU, graphics card, available RAM, etc)

Glad you got rid of your black lines, a couple of small things to add: For the vertical seam you should do what Alisha suggested, I somehow missed that in your post, despite the CAPITALS. The lower 3 islands on your map are almost touching the edges of the texture. If you make them touch exactly, the bleeding will be from one side of the texture to the other, so you would never see a black line. For the horizontals this won't work of course.

You could downgrade your graphics driver. A quick search resulted in this. Make sure you read very well before installing. The HD4000 doesn't meet the minimum requirements for SL (going by the benchmarks), so even if you had no problems before, I don't think you can expect any fix or support from LL.

Not only the vase has LoD models, textures do as well. You can see this when you zoom in on something in the distance quickly (something that you haven't seen from up close yet). You'll see a blurry image for a while. So if your texture doesn't bleed on the high LoD model, the lower resolution on a lower texture LoD can still cause bleeding. On top of these texture LoDs, which are controlled by SL, there is mipmapping. If your texture is small on screen, your computer will "shrink" the texture to try to match texel and pixel on screen. If this is your issue, I can think of two ways to fix it. - You say you kept the UV well inside the "light" zones. You could keep them inside even more. - Or you could remap the object. You have a lot of wasted texture space. From a vase I'd expect pretty much a single square for your UV layout. The in- and outside bottom could either be a "saw blade", like in spherical mapping (if you have a vertex in the centre), or two circles. (This is assuming no parts of that map are used for an ear of the vase) The least amount of seams possible, the smaller the chances of bleeding. Another thing I can think of is corrupted cache. All texture LoDs are stored in your cache. If one is corrupted it will be blurrier and (I suspect) bleed more. btw, using your full model for 3 LoDs sounds like a bad idea, performance wise. I understand it won't lower your LI, but simplifying your lower LoDs will save rendertime. On a single vase that won't be noticable, but on a chinashop it will. If the vase takes up 4x10 pixels on your screen (or something like that), you really do not need a lot of geometry, or a well seamed texture for that matter.

Lots of info and tutorials here: Polycount Wiki (Don't skip the "fundamentals" section) Or here: GameArtisans Here: BlogSpot Or here: 3dTotal

I'm well aware the normal map does more than a bump map. Reading back my posts I understand that wasn't very clear. Either way it never hurts to show the difference. btw I tried turning some bump maps into normal maps. The effect between the two is not exactly the same, afterall they aren't the same, but it's safe to say you can't get the effect of a directly baked normal map this way. One thing I'm curious about though. You say you took the height channel from the normal map and used it as bump map. I suspect that would be the A channel, a channel not always included in a normal map and from what I understand not something that will be implemented in the new material system. The only reason to include this channel would be (I think it's called) parralax mapping. To my best knowledge all a normal normal map does is change the direction of the normal. Height is suggested by the normals, not by actual height data. The way I thought I had it figured out was the R, G and B value determine a point on a hemisphere. The direction of the normal is then from the center of this sphere to the RGB point.

Chosen Few wrote: I think you might have missed my meaning of "one-dimensional effect". The point is there's no way with a bump map to get a single texel on a surface to face any particular direction. All you can do is raise it or lower it, along the surface normal. With a normal map, the texel can not only be raised, but also rotated. There's a huge difference there. You're right, of course, that with a gradient, you can create the apearance of a slant in a group of texels, by increasing the rise incrementally from one to the next. But still, each individual texel faces the same direction as the surface normal. So, it's basically a staircase, rather than a ramp. Assuming the resolution is high enough, the steps can appear smoothed out, but since no single texel can be turned to reflect along a tangent like it can with a normal map, the results won't be as realistic as they could be. As for normal maps using less render time, I'm not completely sure on that one, but it makes sense. Theoretically, the more information is precalculated, the less has to happen in real time. I understood your meaning of 1 dimensional, I know that a bump map in essence "tells" the renderer how high the texel should be, nothing more, nothing less. What bothers me though, is the fact 3ds Max (and again I bet the other programs as well) can convert a bump map to a normal map. You can even turn a bump map into a normal map in Photoshop. In order to do that, the software needs to calculate normals, or the entire surface would be "normal blue". This might be the reason why you can have a 3D light effect with bump maps, but it takes more calculation to get the result on screen, obviously resulting in the longer render time.

Thank Panic Mode for posting the solution, not me It seems to be some issue between Win7, AMD cards, SL and by the looks of it HDMI.

My previous computer (now downgraded to media box so still in use) is connected to my tv with a HDMI cable. The card sitting in that box is a factory underclocked 9600GT (EN9600GT). No problems at all running SL, except for the client side lag of course. Maybe it's a settings issue with the AMD cards. In another thread someone had the black/white issue and fixed it: radeon HD 7850M - not working with viewer Message 2: "Go to control panel > apperance and personalization > personalize and select one of the "Basic and High Contrast" themes. I didn't even have to shut down the frozen viewer. It insantly loaded correctly."

In the past NVidia used to make several versions of a card with the same number, GT, GTS and GTX. If I'm not mistaken the GT was the base model, the GTX the top one. The current line of NVidia cards doesn't have these different versions per card. There are two 650 and 660 cards, the 650/660 and 650/660Ti, which have different chips. Then there are the M versions for laptops. The lower end cards (up to 645) are called GT, the higher rated ones are called GTX. I see some GT650 cards online, with DDR3 memory instead of the faster DDR5 memory in the GTX650. I don't see the GT listed on NVidia's website though and I don't see any comparisions between the two. In fact I can find so little about it I begin to wonder if it's actually a card that exists. I do see a GT650M with the DDR3, maybe that's it. Whether upgrading to a higher end card will increase your SL experience depends on a lot of things. Generally speaking, the faster the card, the better your experience.You can compare the two cards you mention by looking at some benchmarks, this doesn't tell the whole story, but gives you better (easier to understand) information about its performance than looking at the specifications. The GTX650 benchmark score is 1800, the GT630 780. Compare this to the (almost useless for SL) onboard HD4000 which scores 471 and the top scoring GTX680 with 5548 and I think the upgrade will make a real difference for you but it won't allow you to turn on shadows and other fancy stuff the entire time. The recommended 9600 (GT?) scores 758 btw. Sorry for all the numbers I took them from videocardbenchmark.

For what it's worth, I see this issue coming and going. Sometimes it's mesh, sometimes it's notecards. My experience is it takes a few days then cures itself. I never found any consistancy.

Chosen Few wrote: Bump is a one-dimensional effect. It just simulates height (protrusions or intentations in the surface). Normal mapping is a fully three-dimensional effect. It not only simulates the height of surface detials, but also the direction they're facing in 3D space, for a much more convincing look. You can think of a normal map as a bump map on steroids, if you like. Still with a bump map you can get a real 3D effect by using gradients and you can even bake them into normal maps. I thought the big difference was the way and moment they were calculated in the rendering process. Bump maps using less storage space (and therefor streaming time), normal maps using less render time. Displacement maps are different. They move the actual geometry of the model. Sculpt maps are displacement maps, for example, as are some of the channels in RAW terrain maps. If you have enough polygon density in a surface, you can use a displacement map to do the same thing a normal map can do on a much lower-poly model. But for real-time purposes, that wouldn't be terribly useful. The point in using a normal map is to simulate the look of a high-poly model, while actually using a low-poly one. For realtime rendering displacement maps are pretty much useless, no argument there. One small addition though, in the current 3ds Max materials (so I bet also in Maya and other programs), you don't need the dense geometry for a displacement map. This is a material feature though, not a modifier, that does need the actual geometry. Since in the final render (with the displacement material) surfaces are moved, I suspect to the renderer it looks like there's extra geometry. I'm not exactly sure how that works.

Nacy Nightfire wrote: Is something different going on with the SL texture thingy (technical term) which preserves resolution when you ask it to repeat the exact same texture the exact number of times in SL? Not sure if you already grasped it, but the 1024x1024 (or any other size) repeated in Blender, 3ds Max, Maya or SL stays 1024x1024. That's why you can get away with a lot less resource use when you repeat them. A 2x2 texture repeat on a 1024x1024 texture gives the detail of a single 2048x2048 for a quarter of the memory use. The downside of course is, you can only repeat, so lighting effects or shadows or anything are difficult to bake in. That's why people are asking for a seperate light map in the/a new material system. Then you can repeat the diffuse texture and keep a single (small) map for the shadows and such. (What I'm going to say isn't entirely accurate as far as terms go, but it does explain how it works) A texel is a texture pixel on an object, unlike a "normal pixel", which is a pixel on screen. It's as simple as that. Imagine a plane with a 256x256 texture on it, when you zoom in so it covers the entire height of your screen (roughly 1000 pixels), every pixel on screen will be about four times smaller than the texel, giving a blurry effect. If you use a 1024x1024 texture on that plane and zoom in so it covers about a quarter of the height of your screen, every pixel on screen is about 4x4 texels big. The texture will appear sharp, but you use 4x4=16 times more memory than needed.

In addition to Chosen's answer, you can minimise the bleeding by remapping your object. The black lines show in places where I'd never expect them. You want the edges in the least visible places, not across a button, but on the back. Pushing your UV edges to the very edge of the texture can also help in some cases. Your bracelet for example could be unwrapped in a perfect square covering an entire texture. Then even if you get a lot of bleeding, it won't be visible at all. You can do this in one or two directions btw. Whether it's possible of course depends on how many objects/faces/islands you put on a single texture.

Charles Hera wrote: So "in blender" they were perfect, but when uploaded they were not when joined to another object. Again, the VERY SAME file was used to upload the problematic part with success. I didn't change a THING (honest). Well isn't that your problem? When you join objects the normals might flip. So in many cases you DO need to change things. Did you check your normals before and after joining or just before?

Cubboboy wrote: I have seen people with slower internet than mine be able to max out settings with over 100fps. That would have to be in an empty or near empty sim. 100 fps is simply not anything you should focus on when running SL. I run SL on a pretty high end system (3770K, GTX670, 16GB1600 DDR3 and SSD) and would see 100 fps in some places if I hadn't turned VSynch on. In crowded areas even my system struggles on ultra settings and it won't be able to draw more than 20-25 fps. SL is user created, meaning you see about a quarter of the quality for a tenfold of the geometry and texture use (just estimating on all of those) compared to a profesionally made game. Somehow I get the feeling that if lowering the settings doesn't help your framerates, something you mention and something I experience every now and then, it's just the CPU not being able to feed your GPU fast enough. Just a feeling, hunch or idea, I really am not sure about this. Two questions: Do you see the low fps (same for low and high settings) on all sims or just a couple? What exactly do you consider low fps?

The only insight I can give you is that adding bones isn't an option. So you'd have to rig to the lower arm (elbow). Depending on the animations you use that might or might not work.

Well yes it fixed it, but it doesn't explain what exactly was wrong as in what part of the collada file (or uploader code) was corrupt. SL supports smoothing groups alright, well, kind of. If you upload a box, which uses either 5 or 6 smoothing groups, SL will split the verts where different groups meet, effectively disassembling the box into 6 individual entities which then of course have sharp edges between them. This means the box in SL has 4x6=24 vertices instead of the 8 vertices it has in your modeling program. So the internal SL format doesn't understand smoothing groups (in SL smoothing is determined by a single normal per vertex), but the uploader does (or at least it should )

Odd, taking in mind Autodesk was one of the devs of Collada. Anyway, 3ds Max does the very same as Maya, export a simple box as dae and import it back and the dialog will show the error. I never import dae files really, so I never noticed. @OP, glad you were able to solve it as well, but I still have no idea what the issue is exactly.

I think something in the model is corrupted, importing into 3ds Max gives me the following fbx error: While reading or writing a file the following notifications have been raised. -Warning: The transform of node "polySurface1" is not compatible with FBX, so it is baked into TRS. The file opens, but exporting then importing in SL results in the same error you get. (No idea if the errors are related.) Unlike your pictures from Maya show, the model was faceted. I don't use Maya, but in 3ds Max I was able to export and upload by setting all the polygons to the same smoothing group. Maybe that's a clue.

What exporter (and version) are you using? The Autodesk 2012, 2013.0 and 2013.1 FBX plugins don't seem to work with SL. At least that's the case for 3ds Max and I suspect Maya uses the same format. You can download the 2013.2 or 2013.3 version from Autodesk, alternatively you can take your exported fbx or dae file through the 2011.3 FBX converter.

LL is working on support for normal maps as we speak. Last thing I heard was the servers are ready, but the viewers aren't yet. Anyway, in the (near) future you can add a lot of detail to a low poly object exactly like you see in the tutorial. Pretty much all objects can look better with normal maps, think about tiretracks, small buttons, brickwork, woodgrain, clothing details, anything that's not completely polished flat.

Creed Aldrin wrote: Well, in my everyday experience i consider 45 FPS as life-smooth, and less FPS is worse to my eyes. I see it. Maybe avatar movement doesn't bind to FPS and "avatar FPS" is worse than scene FPS. IDK. But i see it for sure. The fps you want to look at is the one that is on top of the ctrl shift 1 menu. The sim fps does not show on your screen in any way. There is no "avatar fps", there is screen fps and there's server fps. One is visual, one is completely server side. You can have a sim running at 1 fps and sill have a very smooth experience as far as visuals go, you can have a sim running at 45 fps and have a stu-stu-stutter on your screen. The two are depending on some shared things, for example if a "heavy" avatar enters the sim in your view, both fps might be affected, but that doesn't mean the sim fps will affect your screen. More importantly, the end user can do all kinds of things to improve the screen fps, such as lowering the load on their computer or uprading their computer. One can't really do anything about the sim fps, unless they are either the main offender of server load or if they have full control over the region.

Helium Loon wrote: Sorry, Chosen, but in this case I'll have to side with the developer of the converter. He did give answers. You don't like or agree with those answers. That's fine, but don't say he didn't give them. I have to "side" with Chosen. None of Chosen's questions were answered as far as I can see, in this thread or the previous one. I'm (still) having the same reservations. Maybe an example would clarify things? An example where the external tool is preferred over using a 3D program. I have a lot of scuplt maps I've created over the years. I'm lucky if I can find the hard-drive they are on (if it even still functions!) Having the ability to deconstruct them to OBJ format isn't a bad thing. And sure, I could install Blender (if I didn't already have it) and take up 20-30 Mb of space and plenty of time downloading and installing. Or I could use a command line tool. And what about if I have a whole directory of sculptmaps I want to convert? I haven't discected the applescript to see if it handles wildcards, but a quick shell script could do that and call the script for each. Doing that through most plugin GUIs in a 3D modeller isn't possible. You'd still need Blender or any other 3D program. First of all, you can't upload an .obj file, so it needs to be converted to .dae. Even if you didn't have to convert, what would be the purpose of uploading a sculpt as dae file/mesh? The triangle count and UV layout would still be just as (un)usable as a sculpt, most likely with a higher landimpact. Converting would only make sense if you optimise the .obj file in a 3D program before export. Now Chosen's (and my own) point is you could import the sculptmap directly into Blender, or any other program of choice, without the extra step of converting to .obj. And it should be mentioned that just because something CAN be used in an illicit manner does not preclude its usefulness outside illicit activities. VCRs and now DVRs both have illicit uses. But they also have perfectly acceptable uses. And while there are other ways of accomplishing the same activities without using them, that doesn't always mean it is the most efficient, or the most convenient. I still don't see how using a seperate tool would be more efficient OR convenient. And even if there were no particular use for it, it can serve as a basic algorithm for those wanting to understand how to write their own utilities for dealing with sculpt maps. *shrug* No argument there, but that doesn't change the fact it's pretty pointless to convert a sculpt to mesh just for the sake of converting a sculpt to mesh.

Avant Scofield wrote: How about this use? My hard drive died and I lost all my sculpt models that I was hoping to develop more as mesh items. Since I can still grab the sculpt maps from SL, it seems like this program would be able to help me. Since you were able to produce sculpt maps before your crash, you should be able to import them just as easily. Like Chosen said, why use an external tool if you have the internal one available? You can import sculptmaps into Blender, into Maya and into 3ds Max. It might require a plugin, but that's probably more user friendly than an external tool.