the VRMesh format will be supported. Still trying to speed up some stuff for RT before moving on to Proxies. I've managed to get scene parsing time down considerably (in many cases), but it's still not as fast as we would like it to be for RT updates. Then once we have regular geometry, groups, and components whizzing about, Proxies will be icing on the cake, and allow Sketchup to have some heavy geometry such as xfrog and evermotion assets.

I like to hear what's wrong with the product first hand if I can, and this community is a pretty good place to go to hear about issues. Of course I always prefer actual bug reports with detailed information, screen shots, scene files, error logs, etc But some people prefer forums over bug reports ::shrugs::

I only hop on to forums while waiting for something to load/finish. (was waiting for 100 or so objects to move in RT... looks like I need to optimize things a bit more...) No worries, we'll get ya up and running. Setup is usually pretty quick and simple.

Keith sent you an email requesting a remote session so he can fix this for you. That's an odd error to get with no plugins installed and just doing a typical install on windows.

actually, here's the benchmark code I ran

class Magic;def initialize(&block)
	@block=block;end
	def ===(other)
		@block.call(other)
	end
end

def GetVrayImportantArrayFromGrepDrawingelement(entities)
	return entities.grep(Sketchup;;Drawingelement){|ent| false == (ent.class == Sketchup;;Edge) ? ent ; nil}.compact
end

def GetVrayImportantArrayOfTypesFromGrep(entities,typeHash)
	for curType in typeHash.keys()
		typeHash[curType] = entities.grep(curType )
	end
end

def GetVrayImportantArrayFromGrepMagic(entities)
	return entities.grep(Magic.new {|ent| ent if(ent.class == Sketchup;;ComponentInstance or ent.class == Sketchup;;Group or ent.class == Sketchup;;Face)})
end

def GetVrayImportantArrayFromLoop(entities)
	vrayImportant = Array.new()
	for ent in entities.to_a
		if ent.class == Sketchup;;Face or ent.class == Sketchup;;ComponentInstance or ent.class == Sketchup;;Group
			vrayImportant.push(ent)
		end
	end
	return vrayImportant
end

def RunBenchmarkOnEntities(entities)
	testHash = Hash.new()
	testHash[Sketchup;;Face] = []
	testHash[Sketchup;;ComponentInstance] = []
	testHash[Sketchup;;Group] = []
	
	grep_drawing_ele_result = grep_magic_result = compare_loop_result = nil
	
	grep_drawing_ele_start_time = Time.now.to_f
	grep_drawing_ele_result = GetVrayImportantArrayFromGrepDrawingelement(entities)
	grep_drawing_ele_end_time = Time.now.to_f
	
	grep_types_start_time = Time.now.to_f
	grep_types_result = GetVrayImportantArrayOfTypesFromGrep(entities,testHash)
	grep_types_end_time = Time.now.to_f
	
	grep_magic_start_time = Time.now.to_f
	grep_magic_result = GetVrayImportantArrayFromGrepMagic(entities)
	grep_magic_end_time = Time.now.to_f 
	
	compare_loop_start_time = Time.now.to_f
	compare_loop_result = GetVrayImportantArrayFromLoop(entities)
	compare_loop_end_time = Time.now.to_f
	
	puts "drawing_ele_test time; #{grep_drawing_ele_end_time - grep_drawing_ele_start_time}, resulted in #{grep_drawing_ele_result.size} elements found"
	
	puts "types_test time; #{grep_types_end_time - grep_types_start_time}, resulted in #{testHash.values.flatten.size} elements found"
	
	puts "magic_test time; #{grep_magic_end_time - grep_magic_start_time}, resulted in #{compare_loop_result.size} elements found"
	
	puts "loop_test time; #{compare_loop_end_time - compare_loop_start_time}, resulted in #{compare_loop_result.size} elements found"
	
	return nil
end

RunBenchmarkOnEntities(Sketchup.active_model.entities)

Just ran a benchmark in a scene with 10,000 edges, one component instance, one face, and one group. It appears that grepping specific classes you are interested in, is faster than doing a more general grep and then comparing within the block.

sample code soon to follow

drawing_ele_test time: 0.00999999046325684, resulted in 1103 elements found
types_test time: 0.00999999046325684, resulted in 1103 elements found
magic_test time: 0.0420000553131104, resulted in 1103 elements found
loop_test time: 0.0190000534057617, resulted in 1103 elements found

that's my results from the huge one-liner that I copy and pasted for a scene with 13108 total entities. 10,000 edges, 1,000 component instances, 1,000 groups, 1,000 faces. The goal was to find anything that could have a material applied to it, so I wanted to filter out edges.

So actually it appears my test was flawed. I'm adding entities to a hash, and looping through the desired types in the "types_test" results. In the "drawing_ele_test" I am just doing a comparison to see if the type matches one of the types I am looking for. They both end up taking the same exact amount of time, so there's probably a cleaner way to write this, but under the hood both of those tests are essentially doing the same thing.

Dan, did you try benchmarking your pattern? It might not have much of a performance hit if you have the extra filtering criteria in the grep block:

@unknownuser said:

Don’t forget the extra processing — a map operation — comes “free” if you provide grep with a block

Enumerating Enumerable: Enumerable#grep : Global Nerdy

Once again, it’s Enumerating Enumerable time! This is the latest in my series of articles where I set out to make better documentation for Ruby’s Enumerable module than Ruby-Doc.org’s. In this installment, I cover the grep method. In case you missed any of the previous articles, they’re listed and linked below: all? any? collect / […]

Global Nerdy (www.globalnerdy.com)

Glad I got frustrated on Wednesday and started throwing stuff at the wall to see what stuck! Nice benchmarks Thomthom, hope my find can help some folks out!

I hope you get up to speed in time for beta to start. The next version has a bit more pep in it's step.

@holmes1977 said:

@thomthom said:

@holmes1977 said:

@thomthom said:

They will be at Basecamp - maybe they can show of something? At least I'll quiz them on a status update.

Didn't realise they were going to be at base camp. Go get em thomthom

Check out the updated Basecamp website with the schedule: https://sites.google.com/site/3dbasecamp2012/home/session-descriptions

Thomthom..........can you grill them on instancing/proxy for me.

Couldn't get proxies in there (and presentable) in time for Basecamp, but they're on the way.

Sorry we've been so quiet guys. We've had some optimization improvements, stability improvements, and a few new features added to the latest dev version, but it's just not quite ready for a beta. We've been quiet, because we've been busy pounding the keyboard. Corey and Fernando should be at Basecamp this year, so you should be able to take a peek at what's going on if you're going, and you can ask them what's going on behind the curtain. We've knocked out pretty much every reported bug from 1.49.01 (other than comments such as "this button is too square" or "maybe you should change the text alignment", so thank you to everyone that took the time to send in those bug reports. RT is up and running for the most part, as is the dome light. I'm sure Corey and Fernando will be more than pleased to show off the rest of features and improvements. Once we are at a point where we are prepared to take in new tasks and a fresh list of bugs, we will be starting up beta. As Vlado mentioned, that time is coming soon. We really wanted to kick it off sooner, but we also didn't want people testing something that was obviously not ready.

we didn't want our lights to clutter up the component definitions, so we use groups. When we go to look for lights in the scene, we don't check any components, we only check groups. You can put the light group in the component, that's fine. You can not convert it to a component directly though, or we will not know what to do with it.

If you convert the light group to a component, it will prevent the scene from rendering. We see that happen a lot, people want to have instances of the same light so they just convert the group, thinking everything will be fine. In order to have that functionality though, you need to place the light group inside of a component, rather than converting the group to a component.

well... I'm always asked what the status is for this or that, and I figured I'd show what I have to show, that I can show (at least I don't think anyone would yell at me for leaking that...) Otherwise, everyone starts to think that we're sitting around eating sushi or something (as appealing as that may sound, and as much as we may wish for this, it's not what we do all day).

I wouldn't call it a beta, but yes. It's the current status of development, in regards to that feature.

we are striving for better host application integration, so we will support that if we can do it in a timely manner. We are trying to not let this development cycle take too long. We have had requests for per scene visibility changes for animations sent to us by users in the past. The difficulty is that with the way things currently are set up, we have to basically restart the whole scene parsing process again for each scene if we want to account for visibility changes, which slows down animation renders considerably. We definitely see the value of supporting this, but we haven't found a way to avoid the speed hit yet. Once we do, we will be adding it.

it will be in the next release: http://screencast.com/t/mqfvvDv390Ev

http://screencast.com/t/5WExF9cF <-- like this?

excellent, I believe the standalone dongle can hold a VfS dongle license too, so you probably won't be waiting in line with the other beta testers