ah mozzie,
It's actually not too OT at all
There are a number of known problems with SU2LUX's settings atm,
and I ran into this problem when trying to fix them.
If you want I can share what I have so far, and it should work
fine on SU7 and perhaps SU8 if the problem is restricted to
my machine but I suspect it isn't... (not that there is too much
to be desired in SU8 free anyway...)

@khai said:

take a look at Luxrender. they are going to implement OpenCL GPU rendering in .8

they already have some interesting work done you can download and try out, and the SU plugin, while rough, does work.

That's what I would have suggested also

SmallLuxGPU is a good working example, and as far as I'm aware OpenCL is just essentially a layer on top of CUDA (at least in Nvidia's Implementation) so you should gain many of the same benefits.

You might need to dig around a tiny bit in the forums to get at it though.

@morisdov said:

If i disable google update service and hide associated exe, i am experiencing noticable delay on closing sketchup or opening a new model.

First i thought i had AppObservr bugs.
Even though i try to code defensively against exceptions and presume surprises.

Yes! That's probably it. I'll check before I confirm that was my problem, but if it is then this is definitely google's responsibility. I do normally close the update service because I don't like to have random processes running in the background on my computer... But this definitely shouldn't affect sketchup usage!

would fxruby or qtruby be other options?

@frederik said:

@11zulu said:

I have seen no mention of :

Guess you didn't make a search then...
You can see it mentioned in the Extensions & Applications Discussions section in the Mitsuba Physically Based Render...

Reason why you don't see it in this list is most likely because there's no exporters developed between Mitsuba render and SU...

I'm pretty sure mitsuba extensively uses the collada format for its scene intake, which I would call support for sketchup, wouldn't you? Plus it's fast becoming popular.

@tig said:

It takes a blink of an eye to get / to set literally dozens of these settings as the web-dialog opens / closes. You could also make the dialog 'modal' so that the user can't close the model with the web-dialog open and thereby loose settings - I have done this because with my tool you can do several operations with the dialog remaining open and it's only on a 'close' that the current 'fields' get saved as attributes...

So what happens when the user tries to render/export with the settings dialog still open? I would like it to be possible not to have to close the dialog every time you want to render the scene, so it will be easy to make quick changes... I'm guessing you've probably handled it similar to me in that you have a temporary attribute dictionary, that gets save synced to sketchup on demand. So that it should be possible to export your scene whether the dialog is open or not... Either way, does implementing the "syncing" action in the deactivate(view) prevent it from being registered in the undo stack? Your solution to the problem does sound like it could work for me. Could I not also do it like like this? WebDialog.set_on_close{ save_settings(blabla)}

If I do it the way you suggested at least the user will will have the option to undo the changes, I just worry about it getting in the way of the modelling workflow, because it essentially creates a point where the user can no longer undo changes they made in the model. There really should be two undo stacks running in parallel ?

@thomthom said:

But isn't it just as likely the user might want to undo these setting changes?

yes, but unfortunately, they can currently undo changes they made in the settings editor even when it's closed. They won't be able to tell that they've undone them. Perhaps, like me they might think they just mispressed the ctrl-z key, or just keep pressing it until something visual undoes (like the removal of a line), and later discover that they've just undone all the changes that they made to the settings, and there is no way to redo, because they've continued on with their work.

This is entirely plausible because I've done it myself! While it isn't too much of a loss at the moment, I can see it getting pretty bad later on, plus, any little change like ticking a box or whatever adds another undo to the stack, which means that when alternating between modelling and changing render settings, they have to delete the changes they made in the settings editor AND press undo many times just to get a visual response... (hmm I could have made that bit shorter )

@unknownuser said:

Have you tried that bare-bone example with no other plugins installed?

yes, in both sketchup 7 and 8, but I'm thinking I'd better try mucking around some more to see whether it's another problem with my sketchup installation, because it doesn't seem to be giving you guys any problems. But you are right, because it could be an observer in another script interfering with this one or something. Oh well, unfortunately the solution isn't that simple

Thanks for the help anyway thomthom (and TIG of course ). Hopefully I can get a reasonably feature complete su2lux out soon for people here to test. I'm going to be doing a bit of Arch-Vis work over the coming holidays, so I have a vested interest in this project!

edit:
oops, didn't see that last post TIG, I'd better reply to that too!

Thanks for the replies guys!

@thomthom said:

eh? he doesn't mention anything about any tool...

thomthom is right, it's not a "Tool", its an exporter for sketchup to luxrender.

Previously, settings were saved to the sketchup attribute dictionary when any change was made to the setting in the settings editor. This system does work, but it also means that after changing settings, or perhaps using/loading a preset it leaves stuff behind in the undo stack, which the user might inadvertently undo and thus lose any changes they made to the settings. I've changed it save all the settings to a temporary array until the model is saved. Which works fine in sketchup 7, but sketchup 8 seems to be having problems.

@thomthom said:

That bare-bone sample you provided cause a 5min lag on your computer?
What OS?

Not 5 minutes, but 5 seconds rather. I might do a little more testing to further narrow the problem. But for someone who likes to save fairly regularly, 5 extra seconds is kind of annoying, and I'm imagining it might annoy some users as well. The same lag occurs when opening a new model with these observers activated.
BTW: I'm using windows xp sp 2.

@thomthom said:

AFIK there isn't a way to make an operation fully transparent to the undo stack.
What type of data is it you want to store anyway?

I'm just trying to store a mapping of settings to their values.

I've run into some trouble with sketchup's application observer and model observer when using the onSaveModel, onNewModel and onOpenModel. Basically, whenever I save, open or create a new model it lags like crazy... ok, maybe not crazy, but 5 seconds is enough to get on my nerves, and I'm sure that's pretty unacceptable for any script, as it will most likely get in the way of the user... I've stripped down the problem to this code and it still occurs, so I'm thinking it probably isn't fault of mine, but if you think it is, please let me know

Interestingly enough, my code runs without a hitch in sketchup 7, so I'm thinking its a new problem. I'm surprised no-one else has run into this problem yet, or does no-one use app/model observers?! or perhaps it's just my computer? (yes I have reinstalled sketchup 8 just to make sure, and yes I have tried with a totally clean script directory.)

Any help here would be greatly appreciated, because I'm relying on this to fix/hack around another problem I'm having:

Is there any way to register an operation that will be invisible to the user? I havn't found a way, and I would like to save all my script's properties into sketchup's attribute dictionary in one hit without having to worry that the user might accidentally undo the saving of the properties. I finally decided that the only way to get around this would be to save the properties when the current model is saved.

class My_model_observer < Sketchup;;ModelObserver

  def onSaveModel(model)

    puts "SAVING MODEL"

  end

end



class MY_app_observer < Sketchup;;AppObserver

	def onNewModel(model)

    puts "NEW MODEL"

	end



	def onOpenModel(model)

    puts "OPENING MODEL"

	end

end



Sketchup.add_observer(My_app_observer.new)

Sketchup.active_model.add_observer(My_model_observer.new)

To the guy asking for sketchup -> luxrender... I'll continue work on it after finish my last high school exams (ever, yeah!)