ChinRey
-
Posts
8,379 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by ChinRey
-
-
24 minutes ago, Pixels Sideways said:
Why does it do this and how can we lock in the 4LI and prevent it from reverting to 22LI?
It's really annoying and screws up the LI cont on the parcel,
The most likely explanation is that the 4 LI readout in the viewer is wrong. That happens every now and then. If this is the case, there's not much you can do about, 22 LI is the correct number and it's what the server operates with no matter what your viewer says. There is one easy way to find out if this is the answer: In the parcel details, check how many prims are used. Then rez a copy of the build and check again.
-
2 hours ago, Chaser Zaks said:
I'd be fine if they recycled older gifts every month if they didn't have anything new. People could get stuff they missed that way.
Maybe but remember that the only reason the premium gifts have any value at all is that they are so hard to get. It's all rubbish, as others have already pointed out, but their rarity makes them collectible to many SL'ers.
-
1
-
-
21 minutes ago, Bedlam Ansome said:
How do create I a sliced Prim to fix one end when stretching along an axis?
For example, when something like a lightsaber blade extends in one direction from a fixed point.
I'm not sure what you mean, this is how the slice function works by default. Alter the Slice Begin and the top of the prim (along the z axis) still stays in the same position. Alter the Slice End and the bottom of the prim is stationary.
-
On 7/23/2023 at 4:02 PM, Charlotte Bartlett said:
A prim house could take 3 hours, a mesh one easily 18 plus for a simple small basic home.
I had to do a test build to fact check this and yes, 18 hours for a house like this doesn't seem too far off. Add two more hours to take some good promo pics and a trip to Hell (aka listing an item on MP) and we're at an even 20.
The OP seemed to be concerned about the possible profits from their build. I've had a house not too different from this listed for eight years now. A little bit more complex but not that much. It took me a lot longer to build but that's ok, I was experimenting and learning so that doesn't relly count. I've sold 17 copies of it so far, net profit about 40 US dollars. In other words: two dollars per work hour.
That's probably what you should expect if you're a moderately well known SL creator. Brand profiling is extremely important in SL so if you're a completely unknown you should expect to sell much less (unless you're prepared to spend even more hours on marketing than on building that is). If you have a well known and well established brand name, you'll probably sell much more.
Or maybe I'm wrong. The SL house market may be more segmented than I realise and I never really focused on family homes. Back when I was making houses I specialised on medieval timberframe houses and smaller rustic cottages and they've sold considerably better than my family homes, although probably not enough to give anything like an RL income per work hour.
-
43 minutes ago, Gabriele Graves said:
I remember reading about the batch draw calls improvements that LL made and thought they applied to rigged mesh too.
That's what I thought too but the Beq posted this on her blog: http://beqsother.blogspot.com/2021/09/why-crowds-cause-lag-why-you-are-to.html
So unless LL has made a fairly major upgrade since then, and I'm sure we would have heard about it if they did, each alpha cut is still a separate draw call.
For those who don't know what a draw call is, each face on each object in a 3D scene, not just in SL but in all OpenGL or DirectX based 3D environments, is drawn as a separate "draw call" by the gpu. Needless to say, each draw call takes quite a lot of time to prepare, the positions of the vertices have to be calculated, the textures and materials have to be loaded from memory and applied to the surface etc. With lots of draw calls this adds up very fast. LL developed a partial fix to this problem, a way to identify and merge faces with identical textures and materials and that helped a lot. Unfortunately this doesn't work with fitted mesh and since each alpha cut is a separate face, each needs its own draw call.
If I understood Animats right, Vulkan has solved this problem but a Vulkan based viewer for SL still seems to be far away in the future.
-
2
-
-
52 minutes ago, Gabriele Graves said:
The introduction of batched draw calls have pretty much eliminated the concerns around drawing performance.
Consolidated draw calls didn't work for fitted mesh last time I checked but that's a while ago. Has this been fixed recently? The big issue with alpha cuts was the many draw calls. If LL has sorted that out, there shuldn't be any problem with them.
-
1
-
-
1 hour ago, Jaylinbridges said:
I don't understand the opposition to alpha layers in this forum.
The opposition is even stronger among fashionistas in-world.
I think it's partly habits. People are used to use alpha cuts by now but they've forgotten how to use alpha layers. But if I understand right (I can't even remember last time I bought any clothes for my SL avatars so I don't really know) many clothes makers don't even include alpha layers in their packages or if they do, they're so off they're not really usable. We can't really expect the average SL'er to make their own alpha layers.
When it comes to performance, alpha cuts add a lot to the render load but they do that regardless of whether they are used or not. Using the cuts will actually reduce the lag slightly. All mesh bodies before Senra have alpha cuts anyway so when it comes to lag, we might as well use them.
-
3
-
-
2 hours ago, ItHadToComeToThis said:
Are we supposed to make our own alpha layers?
Yes.
Or rather, the makers of the clothes are supposed to make the alpha layers too. This is part of the BOM concept and not specific for Senra. It's just that it's so much more critical for Senra since the clothes that come with them are so poorly rigged, if they are rigged to the body at all, and there are no alpha cut workarounds.
-
4
-
-
Awww, sorry to se you leave, Lindal, but I think I understand very well.
I left Second Life myself four or so years ago for similar reasons. As much as I loved being in Second Life at first, it eventually grew old and I got that "been there, done that" feeling. The only thing I still love doing in a virtual world is create big landscapes but that is way to expensive in Second Life so I found another place for it. I still log on every now and then to do some tests or to chat with friends I don't meet anywhere else but that's it.
I never left the forums though. There are too many good people here and besides, I'm still fascinated by the technical aspects of a virtual world. You didn't say anything about the forums but remember that you are always welcome here regardless of whether you're still in SL or not.
-
7
-
1
-
-
4 minutes ago, Persephone Emerald said:
Maybe it's just me, but I thought the ears were too low.
It's hard to tell from the photo but it seems to me the lower tip of the ears are about where they should be but since the ears are so small, the top of them are too low.
2 minutes ago, Tayt3rChip said:And yup , skins can really make or break a look.
You can say that again.... and again, and again.
-
1
-
-
6 hours ago, rasterscan said:
Blends really well skin wise.
Yes, I'm impressed by that too. It's not a mesh head btw so what you see (or rather don't see) is the blend between mesh body and system head.
6 hours ago, rasterscan said:And looks nice too imho although I'd hope its thicker for Blake male
The neck thickness in the picture isn't anywhere near the limits in either direction so that's not an issue. It's the length that is the problem. It's not critical but it's right at the limit of what's acceptable and not ideal. Of course, this and other proportion related issues are less prominent with bigger avatars and there aren't that many people who use RL size avis in SL. But there aren't many who use the goliaths of the past either, most go for something in between these days, and it seems Senra is made specifically for those giants.
(Edit: for reference, my ChinRey avatar is 173 cm (5'8) which is on the tall side by RL standards, very short by modern SL standards and diminutive for an old school SL avi. The shapes that come with the Senra body are actually only 190 cm (6'2) which isn't too tall for a modern SL avatar and rather small for an old fashioned one. They aren't very well proportioned though so we can't really judge by them. It would be interesting to see if somebody could come up with a good looking, well proportioned shape for the Senra at that size.)
Another issue I noticed but forgot to mention is that the UV mapping for the fingers and toes is very different both from the system avatar and from what is common for commercial mesh bodies. That means it'll need skins specially made for the body and I can't imagine anybody would want to keep the poor quality skins included in the Senra package for very long.
4 hours ago, Persephone Emerald said:I don't think the complexity is that bad, though I don't know much about creating mesh.
The Avatar Complexity measurement is just a meaningless number. There are avis with ARC less than 50,000 that can cause serious lag issues and ones with 200,000+ that cause no significant issues at all.
We can however check the two factors that make a difference between different mesh bodies, tri count and alpha cuts.
The female Senra body has a liitle bit more than 45,000 tris and the head a little bit over 15,000. A skilled mesh maker who really tried to make them render efficient would have done it at half so it's not good but as I said earlier, it's still better than any commercial mesh bodies. As for alpha cuts, Senra doesn't have any, commercial mesh bodies have dozens. This is even more important than tri count for lag since each alpha cut requires a separate draw call. So overall, although Senra isn't very well optimized, it's not too bad and certainly far better than any commercial mesh bodies.
-
5
-
-
13 hours ago, ItHadToComeToThis said:
Why the female body and shape make me look like a action man doll in a dress.
That's a poor skin and body shape, nothing to do with the mesh body as such. I only spent a few minutes adjusting my regular shape for it and came up with this:
Not too bad for a quick hack. However, look at the neck:
This is with neck length set to 0! My avatar is a fairly small RL scale one though and that may explain this and some other problems with the shape adjusters. I have a feeling the Senra bodies only really work for old style giant sized avatars.
Also, note that I'm only wearing system clothes here. The mesh clothes that comes with the Senra avatar don't fit if you change the body shape. Seems to be some seriously poor rigging here. If that is indicative of the quality of the dev kit, it may be a good idea for clothes designers to skip it, avoid the license agreement and figure out the rigging themselves. I don't know but I doubt LL can enforce the no reverse engineering clause for people who haven't signed up for the kit, especially since a correct rigging is bound to be quite different from the one they used for their own mesh clothes and probably included in the dev kit.
Overall I kind'a like the shape. I didn't notice any of the common flaws mesh bodies tend to have but I didn't look that closely either so I may have missed some.
From a technical point of view: about three times as many tris as it should have. There's lots of room for improvement there but then again, all commercial mesh bodies I know of are even worse. Add to this that it doesn't have any alpha cuts and we should expect the Senra avatars to be far less laggy than commercial mesh bodies.
-
5
-
2
-
-
2 hours ago, animats said:
The problem is keeping less experienced creators from making a mess in public.
Yes, that's a very important point but there's another problem with this. Most of the mesh we see in Second Life is made by people who think of themselves as professionals or at least semi-professional. They are too in the sense that they charge money for their work. Most of them also use those dodgy shortcuts that really only should be used by happy hobbyists, some because they don't have any professional level skills, others because it's "only for Second Life" so it doesn't matter. One of them once said to me straight out that he didn't bother making proper LOD models because "people buy it anyway".
2 hours ago, animats said:This is why I push automated approaches.
I'm all for automated LOD model generation, it's just that I've yet to see an algorithm that can do it well for polylist meshes. Here's another tree, a birch this time:
This is a fairly simple and small tree (only 12 m tall) so the land impact is only 1.
Triangle counts for the trunk are 84,50, 6 and 6. So reduction between LOD levels are 40.5, 88 and 0 % respectively.
Triangle counts for the foliage are 24 throughout. It can't be reduced enough to make a difference without compromising its shape and it's low enough to start with it doesn't matter.
Can you find an algorithm that can manage something that is even in the same ballpark? I'm not talking about the absolute numbers here, that will never happen. I mean, can you find one that can deduce the relative reductions between the different levels? A fixed percentage from level to level sure won't do; that idea is definitely a dead end and the sooner we get out of it, the better.
2 hours ago, animats said:Rey is right, but she's a first-rate technical artist.
I'm flattered
It's not nearly as difficult as people tend to think though.
This isn't a place for tutorials but I'll share one crucial tip anyway: Think as a craftsman!
I once read an interview of a Norwegian wood crafter and he said he never created a shape out of the piece of wood he was working on, he only brought out the shape that was already there. This is perhaps the most important rule all true craftspeople and artists adhere to and what separates them from the countless wishy-washy wannabes. No matter what materials you use - paint, wood, rock, sound, words, food ingerdients or whatever - you never force it, you cooperate with your materials to make the most out of them.
A good way to implement this rule for 3D models, at least as an exercise, is to start by setting the limits. Give yourself a certain number of tris and a certain number and resolution(s) of textures. Then, when you've done your best, take a break, look at your work with fresh eyes and ask yourself: what can I leave out? Can I do it with less? Remember WIlliam Faulkner's golden rule of writing: Kill your darlings! It applies here too.
Do this for each LOD model and maybe for the physics model too. A good rule is to go for at least 25% reduction between each LOD level (percentages work well as benchmarks but not as absolute answers).
-
If you want smooth, low lag performance with max graphics quality everywhere in Second Life, you need an AMD Ryzen 12000 series or a NVIDIA RTX9090. You have to expect at least ten years delivery time though and that can be a slight problem.
As for GPUs that actually exist, an RTX3060 or 3070 (or a similar AMD) should be more than enough for most purposes in SL. As others have said already, VRAM and even CPU power are often narrower bottlenecks in the SL rendering pipeline than GPU power.
-
1
-
-
2 hours ago, EnCore Mayne said:
can a mesh object be set to Temporary?
As Wulfie said, yes. However, be aware that unlike temporary prims, temporary meshes are included in the parcel's prim count.
-
2
-
-
3 hours ago, 2Tessa said:
I found that the Path Cut behavior of the increments buttons is highly inaccurate.
Yes, this is a known problems. When I need the level of precision you're talking about here, I always use a script to set the values.
-
3
-
-
Here we go again.
To add to Animats' list:
- Replace the viewer's LOD factor with a prim property one. This way it can be adjusted to strengthen only the objects that need it, good content creators would be able to choose the optimal swap distances for each build (it may differ wildly depending on what kind of object it is) and its impact can be included in the LI calculation. Ideally we want a Unity/UE style system where each swap distance can be set separately but that may be too much to ask for.
- Upgrade the prim system to make it more versatile. According to Avi Bar-Zeev who invented the prim system, the reason why LL went for prims rather than mesh in the first place was that they were far more render efficient and required far less bandwidth than (polylist) mesh. Several tests I've done indicate that this is still the case. On two occasions I found that a prim build rendered faster than a mesh with less than 5% of the tri count. More to the point here: Unlike for mesh, auto-generating LOD models for procedural objects is fairly simple so we hardly ever have to worry much about LOD collapses with them. There is no way back to a pure prim based Second Life of course but the more we can use them, the less lag and LOD issues we'll have.
- Upgrade the way the servers handle linksets. Optimising for render load often means splitting large meshes into several small ones or (as I said above) replacing them with multiple prims. This adds more server load though since as far as the simulator is concerned, an object is an object no matter how complex it is and regardless of whether it's part of a linkset or not. There would be a lot to gain if the simulator - or at least some of the simulator's operations - could handle whole linksets as single objects.
- Update the Land Impact formula. It may or may not have been good when it was developed ten years ago but even if it was it does not really reflect the actual load today. Most important in this context is that it seems to give far too much weight to the triangle count, especially the triangle count for lower LOD models, forcing content crators to reduce the LOD more than should be necessary.
- Upgrade or remove the uploader's LOD generator. To be honest, I'm not sure about this one since it will raise the skill requirements for mesh makers quite a bit and we do actually want inexperienced newcomers to have fun building. But although Linden Lab has finally discovered that GLOD is not a good option, they still haven't realized that the replacement they came up with, MeshOptimizer, isn't much better if it's better at all. Forcing content creators to make LOD models themselves should reduce the problems with collapsing meshes significantly. A "soft" alternative to disabling GLOD/MeshOptimizer completely would be to make them optional and not the default.
- Upgrade the uploader's preview image. That tiny little thumbnail isn't really very helpful.
- Promote the beta grid and make it make it more accessible. Or to put it another way: Make it easier for content creators to do test uploads without having to shell out extra L$.
- Teach the people. Many creators of dodgy mesh genuinely want to improve their skills but information how to do it is hard to find and much of it is downright misleading.
- Teach the Moles (and the Lindens). Linden Lab doesn't seem to have anybody on their staff or as contractors who understands how to make well performing mesh for Second Life. Many of them are excellent prim and sculpt builders but they never made the transition to making good mesh. Others have tons of experience from other platforms but no understanding of SL's special requirements (this is especially important when it comes to LOD since SL does it very differently from other platforms but also very relevant for texture handling and several other parts of the content creating process). The result of this is that the official LL builds tend to set a bad example, LL can't provide adequate documentation themselves (that would be the blind leading the blind) and the developers don't have access to feedback and guidance how their software solutions work in practice.
- Burn down Meauxle Bureaux!!! For those not familiar with the region, here's is LL's description: "Meauxle Bureaux is the home of the Linden Department of Public Works, a program focused on improvements related to the experience of living in and visiting the Linden Mainland. This intricate build was lovingly crafted by resident experts for all to enjoy, so come see the ultimate in shared creative spaces!" What it actually is, is a catalog of examples how not to make mesh, much of it even worse than the grim example Animats showed us in the original post. Calling it "crafted by resident experts" is of course a gross insults to the residents who actually know a little bit about how to make mesh but the sim also illustrates how far Linden Lab as a whole (and LDPW in particular) is from understanding even the basics of what has become the main building m,aterial for Second Life.
3 hours ago, Fionalein said:Rewarding bad designers? Soon everyone would create bad LODs for that precious LI decrease.
It won't reward bad content creators if the strenghtening is factored in to the LI calculation. (Slight digression to a pet peeve of mine: do not confuse design with the technical aspect of content creation. Some of the worst offenders when it comes to handling LOD, physics and lag are excellent designers creating models that look gorgeous at full LOD. That's why many of them sell so well. It would of course have been better if they also paid as much attention to performance as they do to looks but at least they deserve credit for what they have.)
4 hours ago, animats said:- Buildings are harder. But lower LODs with see-through or pointy triangles are just not acceptable. Better tooling in Blender to help with this would be a big win.
Here's a tip to everybody who make or want to make mesh houses: Do not under any circumstance reduce the outer walls and the main outer surface of the roof! Those surfaces don't have many tris if you make your main model correctly so there's very little to gain from it both when it comes to LI and actual load.
There are exceptions to this rule of course but very few and you have to really, really, REALLY understand how mesh works to know when they are appropriate and even those who do understand won't usually bother with that level of microoptimization.
4 hours ago, animats said:- Trees are a big problem but an easy fix. Trees are big, and visible at distance. Many trees, including some of the built-in Linden trees, look terrible at low LOD. There's no excuse for this. Trees are easy to impostor with two or four crossed planes with flat images. If the leaves and branches of a tree disappear at distance, you're doing it very wrong. This is where quality control at Marketplace would help.
Impostors would be very useful for vegetation. Maybe not for big trees since they tend to have swap distances beyond normal draw distance anyway but certainly for medium sized plants.
However, look at this:
These are not my best optimized trees, I picked them fairly much at random. The red prim in the middle is for scale comparasion. it's 2 m high, about the same as the average SL avatar. Land impacts are (left to right) 2, 3, 5, 5, 1 and 1. They all share the same two 512x512 textures, one for the foliage, one for the bark.
Here's how the look at lowest LOD:
The big tree to the left is visibly distorted but the swap distance with LOD factor 1 is more than 500 m - two whole sims away. With LOD factor 2 it's over 1,000 m - or four sims.
It's perfectly possible to make detailed, low lag, low LI trees for Second Life. All you need is some attention to details and an understanding of how mesh, textures and SL's dodgy LOD and LI systems actually work. I believe it's the lack of understanding that is the biggest issue.
-
2
-
21 minutes ago, Love Zhaoying said:
..and the Linkset itself knows about the relation of each prim to the other. But the individual prims do not.
Does that sound correct at all?
I haven't actually asked any prims but if they have the local position and rotation and not only the global (not sure if this is the case), they must at least be dimly aware of that Divine Root Prim they are all connected to in mysterious ways.
-
1
-
-
17 minutes ago, Love Zhaoying said:
So..do you mean that llRemoteLoadScriptPin() only runs for the specific, individual "prim" (whether an object comprised of a single prim, or a prim that is part of a linkset) the script is in? And not the entire "object" (linkset)?
That is correct.
-
1
-
-
52 minutes ago, Love Zhaoying said:
Does this mean llSetRemoteScriptAccessPin() only works for the link the script is in that runs llSetRemoteScriptAccessPin()? The Wiki only mentions "prim" but nothing about "links".
Whether the prim (or mesh or sculpt - that's exactly the same in this context) is linked or not doesn't matter. The very concept of linksets doesn't exists as far as lsl functions not specifically made for linksets are concerned. I may be wrong but I don't think the original SL server software was supposed to handle linksets at all, the feature was meant to be purely client side.
The way llSetRemoteScriptAccessPin() is that it assigns a pin, a code to the prim the script is in. This code can be any integer except 0. Once the code is set, it can only be changed by using the function again and it's maintained even in copies of the prim. To disable remote script access you use the function to set the pin to 0.
llRemoteLoadScriptPin() basically works the same way as llGiveInventory() but it has a few extra parameters including a pin integer. If, and only if, the pin matches the one assigned to the recieving prim, the script can be made to run on arrival.
-
1
-
-
6 hours ago, Quistess Alpha said:
Since I've never used that function intensively, does the pin invalidate when the script calling that function is removed? if not. then as a theoretical impractical solution, maybe all the prims could set the pin with a temporary initialization script?
Pin is a prim property so once set it's permanent. That doesn't help in this case though since it'll have to be set before you can use a script to add a running script to the prim and llSetRemoteScriptAccessPin() is another of the functions that don't work across a linkset.
-
1 hour ago, Love Zhaoying said:
Did not know you could do that! (Copy an inventory object to a specific link via script.)
That's the easy part. Here's the test script I made:
default{ state_entry(){ integer ThisLink=llGetLinkNumber(); integer LinkSetSize=llGetNumberOfPrims(); if(ThisLink>=LinkSetSize){ llOwnerSay("That's all Folks!"); } else{ key NextLink=llGetLinkKey(ThisLink+1); llGiveInventory(NextLink,llGetScriptName()); llRemoveInventory(llGetScriptName()); } } }This script only creates a copy of itself in the next prim in the linkset (before deleting itself) but it shuld be easy enough to figure out how to make it move other items and to other prims too.
1 hour ago, Qie Niangao said:This seems to be a one-off thing, so… couldn't a script in root copy a (self-deleting) inventory-scanning script to every link all at once, where it will arrive deactivated, and then manually select the linkset and use Build / Scripts / Recompile Scripts (and possibly Build / Scripts / Set Scripts To Running)
Yes, that should actually work. Thanks a lot, Qie!
1 hour ago, Qie Niangao said:To manage the flood of output they might write it to LinksetData or they could wait for link_message commands from root to do their thing in turn, or…
The problem is that the root script would have to perform completely different operations before and after the reset but I think I have a solution to that too: send a test message to link no. 2. If no response, copy script to all parts, if there is a response, trigger the listing routine for one part at a time.
That being said, this is beginning to look a bit too complicated for a script that really only is useful ocne in a blue moon. Maybe it's better to ask LL nicely to implement cross-linkset inventory functions?
-
1
-
1
-
-
5 minutes ago, Fenix Eldritch said:
Some more info/context would be helpful. What does the routine do to each prim in the linkset?
It's supposed to create a list of the inventories across the linkset. The idea is to have an easy way to locate that texture that somehow got lost inside a 100+ size linkset - or that no copy notecard that messes up the perms for it. I suppose I'm not the only one who has run across such problems occasionally.
The inventory functions are among those few that still don't have any link equivalents and if I have to set the pin for each prim I might as well add the listing script itself to each or even just check all the inventories manually.
-
I'm not sure if this is possible but I'm trying to make a script that starts at the root of a linkset, performs a routine, then jumps to the next part of the linkset, performs the same routine and so on. The problem is that the script is deactivated when it's transferred to another prim. I can't use the regular llRemoteLoadScriptPin()/llSetRemoteScriptAccessPin() solution since the target prims can't be scripted.
Can anybody think of a workaround for this?
It's not nearly as difficult as people tend to think though.
Facebook
Instagram
Twitter
YouTube
Flickr
Lower LOD levels
in Mesh
Posted
One day sounds like a lot to me.
This is not a complex build but with all the curves it's not exactly a simple one to create LOD models for either:
At 0.5 m height it's 1 LI by a good margin (0.7 download weight) and here is how it looks at low LOD - 18 m view distance with LOD factor 2:
I do not know how good or bad this is compared to how others do it and I do not know what people expect but it took me exactly ten minutes to make the LOD models.
It's all about developing efficient procedures and also to learn how much it's necessary to reduce. If you have to figure out how to make the LOD models from scratch for every new build and also spend a lot of time testing models to find the optimal one, there's hardly a limit to how much time you can spend but even some very basic routines will save a ton of time.
Here's another example. This is a mesh with the interior walls, floors and ceilings for two rooms of a house. A bit complex with four window openings, two doorways and two archways but not much more than you'd usually want for two rooms. (Btw. I always try to combine the interior of two rooms in a single mesh since that gives me six faces to work with for the walls, floors and ceilings of each. And unless it's a very small house I always have separate meshes for interior and exterior since they need very different LOD handling.)
15 minutes of work to create LOD models simple enough to keep the LI down to 1 but detailed enough there are no noticeable reduction whatsoever even with LOD factor 1:
Normally I owuld have done it in ten minutes but it's late night here so my brain isn't working too well. I made a mistake with the mid LOD and had to redo it.