Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 08:11 PM |
I can instance large amounts of wedge triangle terrain in the space of a frame - but if i try to delete it i freeze up for a good couple seconds.
currently i am creating the terrain chunk without a wait() - but i need to delete it when the player moves on 1 wedge at a time.
Is there a faster way i can do this? The player can actually create terrain faster than the game can remove it if he jumps into a car. |
|
|
| Report Abuse |
|
|
|
| 20 Nov 2012 08:20 PM |
- remove - parent the object to nil - localize methods/variables
Destroy does a bit more work in removing the object so there's not much room for improvement |
|
|
| Report Abuse |
|
|
xSIXx
|
  |
| Joined: 06 Aug 2010 |
| Total Posts: 9202 |
|
|
| 20 Nov 2012 08:31 PM |
.Transparency = 1 .CanCollide = false
then remove. |
|
|
| Report Abuse |
|
|
|
| 20 Nov 2012 08:32 PM |
| Why would you do that. . . |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 08:36 PM |
Well re-parenting in workspace is basically delay free, re-parenting to lighting takes a couple seconds but once it is there it can be deleted instantly.
So i suspect the delay involves unsubscribing the objects from the physics and rendering since that would have to be done to move into lighting - perhaps setting to transparent and canCollide false also assists in that? I will give it a go. |
|
|
| Report Abuse |
|
|
|
| 20 Nov 2012 08:40 PM |
oh i thought you meant parts. . . Never worked with terrain before |
|
|
| Report Abuse |
|
|
xSIXx
|
  |
| Joined: 06 Aug 2010 |
| Total Posts: 9202 |
|
|
| 20 Nov 2012 08:41 PM |
@sty
he asked that it was too slow.
so how about making the transparency 1 de-collided it (faster) to make it visually look removed? |
|
|
| Report Abuse |
|
|
Tenal
|
  |
| Joined: 15 May 2011 |
| Total Posts: 18684 |
|
| |
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 08:44 PM |
| well the reason I'm removing it is because it already can't be seen (behind the fog) so transparency for the purpose of hiding it is not useful. |
|
|
| Report Abuse |
|
|
Anaminus
|
  |
 |
| Joined: 29 Nov 2006 |
| Total Posts: 5945 |
|
|
| 20 Nov 2012 09:53 PM |
I've encountered this as well. It seems to depend on the size and location of the parts. Getting curious, I made a little test. Check this out:
TIME TO INSERT PART #1 0.00078392028808594 TIME TO INSERT PART #2 0.0007472038269043 TIME TO INSERT PART #3 0.0007932186126709 TIME TO INSERT PART #4 0.00078821182250977 TIME TO REMOVE PART #1 0.017417192459106 TIME TO REMOVE PART #2 0.052874803543091 TIME TO REMOVE PART #3 0.088708162307739 TIME TO REMOVE PART #4 0.12252187728882
Note how the time it takes to remove a part becomes larger each time. Here's the script:
local objects = {}
local template = Instance.new("WedgePart") template.TopSurface = 0 template.BottomSurface = 0 template.FormFactor = 0 template.Size = Vector3.new(1,2048,2048)
local n = 4 local s = 1000
print("NUMBER OF PARTS:",n) print("PART SPACING:",s)
for i = 1,n do local p = template:Clone() p.Position = Vector3.new(i*s,0,0) objects[i] = p local t0 = tick() p.Parent = Workspace local t1 = tick() print("TIME TO INSERT PART #"..i,t1-t0) end
wait(1)
for i = 1,n do local p = objects[i] local t0 = tick() p.Parent = nil local t1 = tick() print("TIME TO REMOVE PART #"..i,t1-t0) end
I've also tried swapping the order in which parts are removed, and got these results:
TIME TO REMOVE PART #4 0.01750922203064 TIME TO REMOVE PART #3 0.017235279083252 TIME TO REMOVE PART #2 0.016802549362183 TIME TO REMOVE PART #1 0.016649007797241
Quite interesting. |
|
|
| Report Abuse |
|
|
Strieken
|
  |
| Joined: 17 Jun 2011 |
| Total Posts: 3058 |
|
|
| 20 Nov 2012 10:18 PM |
@Anaminus
Whaaattt...
How does simply changing the order of which parts are removed have anything at all to do with the speed at which it performs the task..? |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 10:37 PM |
-- first time: TIME TO INSERT PART #1 0.0020074844360352 TIME TO INSERT PART #2 0.003216028213501 TIME TO INSERT PART #3 0.0034167766571045 TIME TO INSERT PART #4 0.0085363388061523 TIME TO REMOVE PART #1 2.7355082035065 TIME TO REMOVE PART #2 3.9051015377045 TIME TO REMOVE PART #3 4.2480661869049 TIME TO REMOVE PART #4 2.7197456359863 -- second time TIME TO INSERT PART #1 0.0022115707397461 TIME TO INSERT PART #2 0.0064723491668701 TIME TO INSERT PART #3 0.0024354457855225 TIME TO INSERT PART #4 0.0064542293548584 TIME TO REMOVE PART #1 0.1973762512207 TIME TO REMOVE PART #2 1.4610180854797 TIME TO REMOVE PART #3 3.2498862743378 TIME TO REMOVE PART #4 9.3417840003967 -- 3rd time around:
TIME TO INSERT PART #1 0.0055642127990723 TIME TO INSERT PART #2 0.0080897808074951 TIME TO INSERT PART #3 0.0052812099456787 TIME TO INSERT PART #4 0.028959989547729 TIME TO REMOVE PART #1 0.44955372810364 TIME TO REMOVE PART #2 3.8296694755554 TIME TO REMOVE PART #3 8.459657907486 TIME TO REMOVE PART #4 12.357916593552 that is very odd.. each time is worse. |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 10:42 PM |
this time using :Destroy() (all insertion times are normal..)
-- first time: TIME TO REMOVE PART #1 0.1712372303009 TIME TO REMOVE PART #2 1.1915714740753 TIME TO REMOVE PART #3 2.5794909000397 TIME TO REMOVE PART #4 7.6356067657471
-- second time: TIME TO REMOVE PART #1 0.15284729003906 TIME TO REMOVE PART #2 1.0931949615479 TIME TO REMOVE PART #3 3.2749519348145 TIME TO REMOVE PART #4 7.3449876308441
-- third time:
TIME TO REMOVE PART #1 0.15901851654053 TIME TO REMOVE PART #2 1.1930377483368 TIME TO REMOVE PART #3 2.567706823349 TIME TO REMOVE PART #4 7.5847299098969
I understand Destroy also releases the memory used by the object - could parenting to nil be causing garbage collect errors to make a difference like that? |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 10:53 PM |
remove() gives very close results to Destroy() and now.. parenting to nil is also giving very close results, about 7 seconds for part 4.
giving it a 1 second wait between deleting objects doesn't help.
however, have a look at this: When objects are anchored:
TIME TO REMOVE PART #1 0.15800476074219 TIME TO REMOVE PART #2 1.2402560710907 TIME TO REMOVE PART #3 2.9499750137329 TIME TO REMOVE PART #4 8.4670512676239
when they are not anchored:
TIME TO REMOVE PART #1 0.0079686641693115 TIME TO REMOVE PART #2 0.024959325790405 TIME TO REMOVE PART #3 0.040202379226685 TIME TO REMOVE PART #4 0.060735940933228
So there is our problem. Un-anchoring everything speeds it up massively, i have tried it a dozen times now and the results are the same - anchored part 4 is 7 seconds +, unanchored its less than 0.1. thanks for that test Anaminus :) |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 11:33 PM |
Some more observations: (i don't mean to spam :o)
Looping through the array as anaminus noted is much faster. the slow down caused by anchoring the parts only occurs if you anchor it -before- you parent it to workspace.
so if you parent it to workspace, then loop through it backwards to delete it i can clear it faster by a factor of over 700.. |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 20 Nov 2012 11:35 PM |
| *parent it to workspace before anchoring |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 21 Nov 2012 12:01 AM |
Last post i promise :D
My conclusion:
Before these changes to delete a chunk would hold my game for > 4 seconds
I then: Made sure all parts are anchored _AFTER_ they have been parented to workspace. Looped through the array of parts in reverse order.
result: the chunk now deletes in 0.11 of a second, each - and every time.
|
|
|
| Report Abuse |
|
|
SN0X
|
  |
| Joined: 24 Oct 2011 |
| Total Posts: 7277 |
|
|
| 21 Nov 2012 12:57 AM |
@Anamiunus (Hope I can finally spell that properly...)
Your test doesn't check the amount of time it takes to insert the part properly. It should just be this:
local tick = tick
t1 = tick() partstable[#partstable+1 = ]Instance.new("Part", workspace) t2 = tick()
Also, I think (not sure though) you can use os.clock() with the command bar.
I'll write my own test later.
Seriously, 12 seconds to remove a part? |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
| |
|
|
| 21 Nov 2012 06:41 AM |
| They probably have a ton of optimization where they have to find and remove 9001 references and tree nodes and whatever to remove a part... o.e |
|
|
| Report Abuse |
|
|
SN0X
|
  |
| Joined: 24 Oct 2011 |
| Total Posts: 7277 |
|
|
| 21 Nov 2012 10:48 AM |
For some reason, yes, you're right: using tick() says it takes seconds to delete parts.
However, I think something's messing with our numbers. When I ran my test, it was so fast, I didn't even see the parts flash up on the screen. Each part I was testing was inserted and deleted without much delay. I couldn't see with my eyes the delay between prints.
My test:
do
local tick = tick -- quicker execution time. didnt do this to instance.new because it's what we're testing local st = 0 -- start time local et = 0 -- end time
local sst, set = 0, 0 -- to find average
local parts = {} -- table of partyyss
local nparts = 1 -- number of parts to spawn for the test
sst = tick()
for i = 1, nparts do st = tick() parts[#parts+1] = Instance.new("Part", workspace) et = tick() print("Part #" .. i .. " spawn time: " .. et-st) end
set = tick()
print("Approx. average part insertion time: " .. (set-sst)/nparts)
sst = tick()
for i = 1, nparts do st = tick() parts[i]:Destroy() -- replace with deletion method of your choice et = tick() print("Part #" .. i .. " deletion time: " .. et-st) end
set = tick()
print("Approx. average part insertion time: " .. (set-sst)/nparts)
end |
|
|
| Report Abuse |
|
|
|
| 21 Nov 2012 11:29 AM |
| Maybe roblox is registering the stuff with the ChangeHistoryService. It would make sense that destroying takes longer than creating if this happens. It would only need to remember a ClassName when it creates something but it needs to remember an entire object when it destroys. |
|
|
| Report Abuse |
|
|
SN0X
|
  |
| Joined: 24 Oct 2011 |
| Total Posts: 7277 |
|
|
| 21 Nov 2012 12:29 PM |
Also perhaps the object is, in the sandbox/physics simulation and what you actually see, destroyed before it actually gets wiped off the memory and all the in-hood stuff happens? (Well obviously, but whatever)
That doesn't explain the weird results, like how I recieve the output almost instantly. |
|
|
| Report Abuse |
|
|
|
| 21 Nov 2012 12:58 PM |
@xSIXx
Simple... yet genius. |
|
|
| Report Abuse |
|
|
Anaminus
|
  |
 |
| Joined: 29 Nov 2006 |
| Total Posts: 5945 |
|
|
| 21 Nov 2012 04:30 PM |
> Your test doesn't check the amount of time it takes to insert the part properly.
No, it does. What I want to test it the amount of time it takes to move parts into, and remove parts from, the workspace. I don't want to include creation of the instance and adding to the table as a part of the test. That's why setting the Parent property is isolated. Your test has skewed results because of the extra processes.
Also, I should have mentioned that this effect seems to depend on the size and location of the parts. That's why I used giant wedges spaced at intervals of 1000 studs. Changing these variables can diminish or amplify the effect. Whether the parts are anchored also plays a role, apparently. What I find odd is that anchored parts take even longer to remove:
TIME TO REMOVE PART #1 0.34391474723816 TIME TO REMOVE PART #2 1.0192921161652 TIME TO REMOVE PART #3 1.7402551174164 TIME TO REMOVE PART #4 5.5381245613098 |
|
|
| Report Abuse |
|
|