Everything related to the integration for SketchUp.
User avatar
By Mihai
#394641
Herbo wrote:
Fri Jun 02, 2017 2:21 pm
With the "render only" feature you can spare sketchup the task of generating the geometry, and it would make the whole process much smoother.
Hi Herbo,

Sorry to bring this up again, but I'm currently writing a tutorial for using the VIZPARK MXS Reference files of their vegetation collections together with Skatter, and I wanted to mention that I've misunderstood part of what this Render only feature helps with. I thought it would help also in the time and RAM used by SU that it takes to generate the Skatter points. But I've just realized the generating time itself and RAM, whether you use Render only or not, is the same. I thought you were limited in terms of that, but that's not the case.

And it's still possible to edit a Skatter group, even with Render only off, so that's not an issue either.

But of course there remains the advantage that with Render only, you can use the Preview limit to only get an idea of where your instances are while still having a pretty responsive viewport. That would be a welcome addition but practically speaking I haven't found working without Render only to be that much of an issue.

For example, even working with a couple of hundred thousand instances, it takes only a few seconds for them to appear in the viewport. Of course I can't navigate with the visible, but I just put them on a different layer and hide the layer. There is also the option in the Maxwell plugin to render layers which are hidden, so in many cases it's really not as bad as I thought. And when previewing with FIRE, I can first unhide the layer and launch FIRE, then hide the layer in SU and the models will still be visible in FIRE, so I can navigate the viewport in SU smoothly to find a better view.

Just wanted to mention all this :P please correct me if I misunderstood something about how Skatter works.
User avatar
By AndreasAM
#394768
JDHill wrote:
Sat Jun 10, 2017 9:00 pm
The problem, Mihai, is that Skatter works and stores its data in ruby space, but the plugin's exporter is a c++ exporter, which does not know anything about ruby (a rough analogy: imagine if SketchUp ran in a browser, and you had implemented something like this on the client side in javascript... and then someone wanted you to render it on the server side). I did discuss with the developer about this already, and the only way to make it work would be by some hack, which I am averse to doing both on principle, and because I expect, after doing so, to find the performance hit to be unacceptable.

Additionally, the plugin's exporter has a limited lifespan ahead of it, given that the API it uses is being deprecated; because of this, and for other reasons as well, its replacement will be done in ruby, and as such, will be able to support something like Skatter without employing hacks.
Mihai wrote:
Sat Jun 10, 2017 5:52 pm
How do you reduce the bounding box of the ref to just show 3 lines?
An MXS Reference is just a component like any other, so you can edit its definition and replace the automatically-generated bounding boxes with whatever you wish.
Any information about when the "Ruby"- plugin for Sketchup is to be expected?
Is this also the reason that Laubwerk's plugin isn't adapted/suited for Maxwell?

A solution for both would be highly appreciated......
By JDHill
#394772
Sorry, but no ETA on the former -- it implies a complete rewrite of the plugin. And this is unrelated to Laubwerk's plugin, which should already be working (I have not tried it myself, but the OP says it is working, earlier in the thread).
User avatar
By AndreasAM
#394781
Thanks for your quick reply, but sorry no,...
I think the OP is misunderstanding what is currently possible with Laubwerk in Sketchup in combination with Maxwell at the moment.

The official statement from Laubwerk on the site is that only Thea Render and Vray are supported for "on the fly" rendering in Sketchup. Maxwell is only supported by Laubwerk in Max, Maya etc.

And that is also my practical experience in Sketchup, so still manually making proxies, i.e. MXS references, before Skattering them.
In my early experiences, what now works is purely related to Sketchup, so inserting of the plants and/or trees in Sketchup from your Laubwerk-library after dynamically selecting age, size, growth and detail. Which are the nicest features of Laubwerk by the way. The trees are nicely modelled. This is, in it's infancy, mimicking Forest Pro from Itoo and has great potential for Archviz in Sketchup, in combination with Skatter (especially in the next Skatter version 2.0 which is currently being developed, with potential implementation of procedural dynamic material/color alterations in each instance).

The MXM-materials, which are accompanying the Laubwerk-models are of so-so quality by the way, and are in dire need of upgrading in my humble opinion (Mihai an advisory job for you?).

But for Sketchup/Maxwell users the problems and or workarounds (making instances) with Laubwerk are currently still the same as with Skatter, that's why I asked if the "standstill" was related to the nature of Maxwell's plugin (Ruby or C++).

I have asked the same questions to Laubwerk today. When they have replied, I will update this thread.

Andreas
By JDHill
#394782
Well, what I can tell you is that we (us and Laubwerk) were in touch about adding some functionality to the (Maxwell) plugin to allow them to implement their system, but I don't know how far they took the development after that point. The result is that the plugin now has hooks that are called pre- and post-export, which can be used (by anyone) to either modify the sketchup document prior to export, or the exported mxs file (and/or revert any changes made pre-export), afterward.
User avatar
By AndreasAM
#394783
Thanks JD, sounds very promising!!

So implementation by Laubwerk could be imminent, nice... Let's wait and see what they tell me in their reply.
Will be Monday I guess, they are strict in Germany, unlike Spain........

Are there specific developments in Sketchup upcoming, that will require the transition of the Maxwell-plugin to Ruby and therefore could make it more a priority on your (probably impressive) "to do"-list? Or is C++ just becoming outdated sometime in the near future?

I am an architect, so I have no real technical understanding how an why Ruby would be preferable for one or the other.

Thanks anyway for your time, attention and information.

Andreas
User avatar
By Mihai
#394786
AndreasAM wrote:
Fri Jun 30, 2017 10:35 pm
The MXM-materials, which are accompanying the Laubwerk-models are of so-so quality by the way, and are in dire need of upgrading in my humble opinion (Mihai an advisory job for you?).
So you can apply any custom MXM to the Laubwerk models? I've never used their system but sounds like a good opportunity to create better materials for their models.
By JDHill
#394787
AndreasAM wrote:
Fri Jun 30, 2017 11:43 pm
So implementation by Laubwerk could be imminent, nice... Let's wait and see what they tell me in their reply. Will be Monday I guess, they are strict in Germany, unlike Spain........
To be clear, it was some months ago that we did this work, so I would personally not speculate on schedule.
AndreasAM wrote:
Fri Jun 30, 2017 11:43 pm
Are there specific developments in Sketchup upcoming, that will require the transition of the Maxwell-plugin to Ruby and therefore could make it more a priority on your (probably impressive) "to do"-list? Or is C++ just becoming outdated sometime in the near future?
It comes down to a combination of factors; the SketchUp C++ Exporter SDK used by the current plugin (and things like the DWG exporter and such, which are likewise restricted to SketchUp Pro, as well as third-party applications, to implement saving to SKP format) is being deprecated, and will be removed from SketchUp in a future release, according to the SketchUp people. They have been working on a replacement for it which is conceptually similar, but at the same time, completely new. However, I do not plan to use that, precisely because of how such exporters exist basically in isolation from the Ruby runtime used to implement plugins; as noted above, the issue with Skatter is that it stores its data in memory in Ruby (as opposed to putting it on the model, which is apparently unrealistic, given the number of "instances" potentially generated), which makes it inaccessible from the context of an exporter (conversely with Laubwerk, if they essentially create temporary mxs references in the model prior to the plugin exporting it, then you can see how that is a "just works" kind of thing). Aside from all that, we then have the fact that we have been working here on a more modern replacement for the aging Maxwell SDK, which is a big job in itself... and it is at the intersection of all these factors, that we find the requirement for, and opportunity to write, a new Maxwell for SketchUp plugin.
User avatar
By AndreasAM
#394789
Mihai,

All materials and textures used in the tree/plamt models are accessible in the tree/plant maps of the library. Materials and textures are dynamically downloaded in Sketchup when using the tree in the model and the MXM's (when a Maxwell/Laubwwrk plugin comes available) are "on the fly" exported with the geometry to the MXS for rendering.
So all MXM's could/can be customized and then subsequently, when replaced in the correct map of the library, dynamically used by the Laubwerk player, I presume. For the moment I use the materials and textures also as a source for my own tree library and build my MXM's for my own specific models.
For most of the species the texture maps are nice enough and of the right level of detail and file size. For some the quality is wanting, but overall good quality to build on.
The MXM's themselves are not very elaborate though, only Diffuse, Alpha and translucency maps are used in each material. Only 1 MXM per leaf, no front and back. Could be related to overall size and speed of rendering though. But there are, per species, 2 or 3 variant leafs for each of the 3 seasons, so a wealth of source material

And as you showed with your hedge and grapevine leaves, a lot can be improved in the overall quality by re-using the available material.

I did some early tests this week for a Hornbeam hedge I needed in my model and most of the diffuse and translucent maps are good enough to be used in a program like Crazybump, to produce more map variants, like Normal (or Bump), specular and even a decent Albedo-variant of the Diffuse.
I saw real improvement when mimicking your hedge leaf material, in just a few minutes, with the acquired material. And I am a novice at this......but improving.

So I can imagine that you can do wonders with the overall impression and quality of the Laubwerk trees after you are done with them.
I know Laubwerk should know better......

Andreas
User avatar
By AndreasAM
#394790
JDHill wrote:
Sat Jul 01, 2017 2:53 am
AndreasAM wrote:
Fri Jun 30, 2017 11:43 pm
So implementation by Laubwerk could be imminent, nice... Let's wait and see what they tell me in their reply. Will be Monday I guess, they are strict in Germany, unlike Spain........
To be clear, it was some months ago that we did this work, so I would personally not speculate on schedule.
AndreasAM wrote:
Fri Jun 30, 2017 11:43 pm
Are there specific developments in Sketchup upcoming, that will require the transition of the Maxwell-plugin to Ruby and therefore could make it more a priority on your (probably impressive) "to do"-list? Or is C++ just becoming outdated sometime in the near future?
It comes down to a combination of factors; the SketchUp C++ Exporter SDK used by the current plugin (and things like the DWG exporter and such, which are likewise restricted to SketchUp Pro, as well as third-party applications, to implement saving to SKP format) is being deprecated, and will be removed from SketchUp in a future release, according to the SketchUp people. They have been working on a replacement for it which is conceptually similar, but at the same time, completely new. However, I do not plan to use that, precisely because of how such exporters exist basically in isolation from the Ruby runtime used to implement plugins; as noted above, the issue with Skatter is that it stores its data in memory in Ruby (as opposed to putting it on the model, which is apparently unrealistic, given the number of "instances" potentially generated), which makes it inaccessible from the context of an exporter (conversely with Laubwerk, if they essentially create temporary mxs references in the model prior to the plugin exporting it, then you can see how that is a "just works" kind of thing). Aside from all that, we then have the fact that we have been working here on a more modern replacement for the aging Maxwell SDK, which is a big job in itself... and it is at the intersection of all these factors, that we find the requirement for, and opportunity to write, a new Maxwell for SketchUp plugin.

JD,

Well the upside is that they've had months to prepare the Maxwell plugin..... but I am well aware that these things take time and won't be ready when you think you need it the most.
Aaaaah the anguish of anticipation...

If I understand it correctly, is that you want to be "ahead of the game" by waiting for the right moment for producing and introducing the new plugin, within or in accordance to the new Maxwell SDK environment, but it will be in Ruby?! I assume that the advantages of a plugin, written in Ruby, being that every step of exporting is within the runtime of Ruby, so producing a more stable, secure and probably faster proces?

It is like waiting for some stars in the galaxy to align.......

Strange that the Trimble-developers don't switch their SDK for the exporters immediately to a Ruby-environment, If there are significant advantages, but keep developing it in a more "'backward'-thinking" separate bubble.

So the Skatter-guys are ahead of the game already? What I mean is, have they taken the same forward thinking path that you are contemplating, by just doing it within Ruby-language and runtime.

Andreas
By JDHill
#394792
Well, not exactly. The c++ importer/exporter API is used both by plugins like ours, and by third-party applications, in order to read & write SKP files in general, and it is a good design for it to be isolated from the runtime SketchUp environment. Furthermore, it can provide very high-performance, compared to what can be expected when working in Ruby. So, it should, and will continue to exist.

The upsides of working in Ruby, on the other hand, have more to do with flexibility, and with having real-time access (and notification of changes made to) the current 3D model. As regards Skatter, with respect specifically to the "render only" feature, the main choice involved (for its developers) is how to store the data; were it realistic to store the data actually on the model, then that data would already be accessible by any exporter using the c++ API; however, with there being potentially millions of instances scattered, this ends up not being feasible.

In other words, none of this is really either/or, black & white -- no matter which SDK you choose to use for a given purpose (when you actually have a choice, technically speaking), there will be upsides and downsides.
User avatar
By AndreasAM
#394800
JDHill wrote:
Sat Jul 01, 2017 6:13 pm
Well, not exactly. The c++ importer/exporter API is used both by plugins like ours, and by third-party applications, in order to read & write SKP files in general, and it is a good design for it to be isolated from the runtime SketchUp environment. Furthermore, it can provide very high-performance, compared to what can be expected when working in Ruby. So, it should, and will continue to exist.

The upsides of working in Ruby, on the other hand, have more to do with flexibility, and with having real-time access (and notification of changes made to) the current 3D model. As regards Skatter, with respect specifically to the "render only" feature, the main choice involved (for its developers) is how to store the data; were it realistic to store the data actually on the model, then that data would already be accessible by any exporter using the c++ API; however, with there being potentially millions of instances scattered, this ends up not being feasible.

In other words, none of this is really either/or, black & white -- no matter which SDK you choose to use for a given purpose (when you actually have a choice, technically speaking), there will be upsides and downsides.
JD,

Thanks for the explanation. Very useful for me.
But it begs the question why Maxwell has chosen to write the next plugin in Ruby. What tipped the balance for you in favor for Ruby in the future?

Andreas
By JDHill
#394801
The basic design of this plugin was created (just) prior to the introduction of Maxwell FIRE; being essentially a glorified file exporter, and the Maxwell SDK being a c++ SDK, it naturally made the most sense to use the SketchUp c++ exporter SDK; not only would this be far quicker performance-wise than exporting from ruby, but it would also not require "wrapping" the entire native c++ Maxwell SDK to make it accessible from ruby. In a nutshell, not much point in doing more work, to end up with something that works slower.

Fast forward, though, and that calculation changes; it becomes worth taking a performance hit up front (meaning time to export), if that means being able to synchronize more things in real time (i.e. camera/materials/environment are realtime already, but say that you did not have to re-export the model when moving objects). Couple this with a new Maxwell SDK, which will be more capable, not to mention easier to wrap for access from ruby, and the decision goes in completely the other direction.
User avatar
By AndreasAM
#394820
JD

Thanks for the input, your motivation for the direction you are taking with the new plugin makes sense. I will follow the developments, if any in the short term, with anticipation.

In the meantime I got a reply from the people of Laubwerk. I quote:

"we have prototypical support for Maxwell already built in for the Windows version of Laubwerk Plants for SketchUp. As soon as the Mac version also works, we will make it public. Should not take too long."

So that's very good news.... they have worked hard on it the last months...
This could also explain why the OP reported that the current player works, (being a Windows user perhaps). I am a Mac-user, so I will wait patiently.

So overall, you're support to Laubwerk will be honoured soon. I thank you for that.
It will greatly enhance my experience in working with Sketchup/Maxwell.

That only leaves support for Skatter........

Andreas
User avatar
By AndreasAM
#394822
I also got some comments from Laubwerk regarding the technical implementation and potential quality on the MXM-materials in the Laubwerk models. I quote:

"thanks for your input in regard to materials. We are aware that there is (and probably always will be) room for improvement. However, one of our strengths is that we can add support for renderers relatively easily, because we base our models on a shared theoretical material model, which is then translated to the respective renderer. The intelligence is in the theoretical base material and the translation logic. The downside of this is that this is actually way more complex than "just" creating a good material for a renderer manually. We will not stop improving the models, though, and better materials will definitely come around."

Sounds that they are on it, perhaps with some help of the Maxwell-community after we have had our first experiences with the new plugin.....

Andreas
Will there be a Maxwell Render 6 ?

Let's be realistic. What's left of NL is only milk[…]