Faster/Better instantiating

Feature Requests Engine Features
#1

TL:DR at bottom of the post.

This will probably be something that would require a lot of calculation power, but I think it would be great to have faster/better ways to instantiate parts. Why am I asking this? Well, Since the featherweight and streaming update, huge maps can be made that aren’t as laggy as they used to be. One thing though that is bothering me, is that this does not however support to ability to create huge randomly generated maps.

Some time ago, I made a cave generator that would instantiate like 10 to 40k parts (I can’t remember how many parts it was). It would take like 2 minutes though before the cave was generated. I’ve also watched SmoothBlockModels twitch stream yesterday, and his map generator also took about 2 minutes to fully generate a map. This is something that might shy away people from making huge map generators for their games.

If possible, I would suggest the possibility to instantiate Parts faster. If this is not possible, then I would at least like a feature to limit the percentage of data used to instantiate Parts. What I mean with that is the following: If you join a server which immediately starts to generate a map, things like animations and other scripts won’t load until the generator is done instantiating stuff. This basically completely limits the player from doing anything. You can’t run any other scripts because the map generator uses too much data with its instantiation [size=2](Not sure if I’m 100% correct here)[/size]. Therefore it would be useful if we could use some ‘spare calculation power’ to run other stuff at the same time and push the instantiating part more to the background.

TL:DR. Add the functionality to limit the data used to instantiate parts or make instantiating parts faster.

[size=2]My apologies if I posted it under the wrong category. I didn’t know for sure where to post it.[/size]

1 Like
#2

100% Support! Randomly Generated Maps are hard to work with when you have to worry so much about the lag the parts created produce.

#3

The thing that is hard about generating huge maps is. You either have to do it with no wait() or the default wait of like .02999999999

If you do it without a wait it takes a lot less time but the player’s screen will freeze while the generating takes place.

What would be cool, but I don’t know how practical this would be to make, is if there was a new wait method that could wait less than the default FPS. Server side only, and it would allow the generating script to wait(.005) each iteration of the generating loop, for example.

#4

How much of that is from the algorithm for generating the map, and how much is from actually instantiating the objects? Have you run benchmarks on this?

e.g.

[code]local totalTimeInstantiating = 0

for i = 1, 40000
local start = tick()
local part = Instance.new(“Part”)
totalTimeInstantiating = totalTimeInstantiating + (tick() - start)
–do other generation related stuff
end

print("totalTimeInstantiating: " … totalTimeInstantiating )
[/code]

#5

It takes less time if you generate it out of the Workspace, then parent the whole map, does it not?

#6

[quote] How much of that is from the algorithm for generating the map, and how much is from actually instantiating the objects? Have you run benchmarks on this?

e.g.

[code]local totalTimeInstantiating = 0

for i = 1, 40000
local start = tick()
local part = Instance.new(“Part”)
totalTimeInstantiating = totalTimeInstantiating + (tick() - start)
–do other generation related stuff
end

print("totalTimeInstantiating: " … totalTimeInstantiating )
[/code] [/quote]
I did not run benchmarks. I’d love to run some, but I don’t know how to do so. :uhhh:
Do I just put this code at every position where I use Instance.new()?

#7

[quote]
I did not run benchmarks. I’d love to run some, but I don’t know how to do so. :uhhh:
Do I just put this code at every position where I use Instance.new()? [/quote]
Basically you’re grabbing the timestamp before you create an object, and after you create it, you take the current timestamp minus the initial timestamp to give you the total length of time (in milliseconds) that it took to create the object. Then you add that to the total duration.

#8

cough missing a do cough

Anyway, why not just grab the timestamp before, then subtract the starting timestamp from the timestamp after all the parts are created?

ex:

local start = tick()

for i = 1, 40000 do
  local part = Instance.new("Part")
  -- do yo stuffs
end

print("Time: " .. (tick() - start))
#9

Because the algorithm for generating the randomized map is probably mixed in with the code that actually instantiates parts. The goal here is to determine how much of the time the instantiation takes vs. how much time the rest of the function takes.

#10

[quote] The thing that is hard about generating huge maps is. You either have to do it with no wait() or the default wait of like .02999999999

If you do it without a wait it takes a lot less time but the player’s screen will freeze while the generating takes place.

What would be cool, but I don’t know how practical this would be to make, is if there was a new wait method that could wait less than the default FPS. Server side only, and it would allow the generating script to wait(.005) each iteration of the generating loop, for example. [/quote]

local PAUSE_COUNT = 0
local PAUSE_THRESH = 256 --bigger = less waits
local function pause()
 PAUSE_COUNT = PAUSE_COUNT + 1
 if PAUSE_COUNT > PAUSE_THRESH then
  wait()
  PAUSE_COUNT = 0
 end
end

function everyTimeYouInstantiateSomething()
 --other stuff
 pause()
end

Flies away

#11

For me the bottleneck is actually the replication of the parts to all clients, not the instantiating (or cloning existing things).
Is it also slow locally?