Posts made by jason_maranto

@rv1974 said:

Traditional one huge sense of shame..

You'd think. But they have proven they are utterly shameless over and over again. I don't know why I bother to open those stupid emails that announce the "new" version every year.

Same story every release. I said ages ago that the problem isn't Trimble (or Google before them) --the problem is the top leadership of the actual SketchUp devs. If anybody is surprised by any of this you haven't been paying attention at all.

While this is certainly drifting off topic from the plugin, I will say there are many options to choose from that are better choices -- for me the choice was Modo.

Modo cost me twice as much as SketchUp Pro (and all the paid extensions I bought years ago) -- however Modo outperforms SketchUp by at least 10X. It is also a rapidly growing package, in the true sense of the word... meanwhile SketchUp stagnates and slowly fossilizes.

I have many packages, I like all of them more than SketchUp.

I have a bunch of reasons -- but the most practical is I have not made a model in SketchUp in over 2 years, largely due to my extreme dislike of the direction (or lack thereof) of development of the software (Combined with the easy availability of much better and much more dynamically growing packages). I did purchased SketchUp Pro 2015, because I publicly said I would if they made the 64-bit change (and I try to keep my word), but the software is really useless to me without a decent unwrap. And so I never used it for a project.

I can put the money that would be needed to purchase extension (and updates) towards keeping my more full-featured and actively growing 3D packages up to date (which have built in Unwrap). To me SketchUp is all but dead -- so I see no reason to "throw good money after bad" into this sinkhole of a software.

I do feel for the authors of these great tools, trying to make the best of an impossible situation... but I am not interested in continuing to endlessly work around SketchUp limitations. And since Trimble does not officially support these extensions, they are under no constraints to do anything to improve the endless workarounds.

Rich asked if people would buy, to help him decide to proceed or not... I answered for myself (and only myself) honestly.

Hey Rich,

As you know this has been a longtime wish of mine. However my stance is that I simply will not give any more money to Trimble until basic unwrapping functionality is part of the SketchUp Pro Suite (I envisioned something stand-alone like Style Builder or Layout).

So, while I really want this functionality, I cannot request you build it... because I have frozen all spending on SketchUp (or SketchUp extensions) until such a time as they (Trimble) pull their heads from their rectums.

The "technology:meal" analogies miss the mark because food doesn't really change. Technology however does change, these days at a frighteningly frantic pace. Yet SketchUp doesn't... watching the development is almost like watching moss grow on a rock.

The writing has been on the wall for several years regarding the slow strangling of a once promising package -- but I guess some are happy to "go down with the ship".... or "fade away into obscurity together".

For myself, I don't have money to waste on a software that is not keeping pace with technological developement (or the third-party ecosystem artificially propping it up). I do find it hilarious that they (Trimble) expect users to buy the updates, sight unseen, via continous subscription... plenty of suckers out there I guess.

I have to laugh at the blatent display of a startling combination of greed, ineptitude and lack of vision/leadership. Under normal circumstances I might expect them to be ashamed of themselves... but I learned a while ago they have absolutely no shame.

LOL

I am glad you found a workflow that will allow you to incorporate Substances -- they are worth it IMO.

FWIW -- IMO the "jumping in" approach will serve you best. There really is no need to fear UV layout, or even using other packages. It is a pretty straightforward process once you get into it. And in the end you will be better off for understanding it... even if you come to the conclusion the workflow doesn't suit you.

Also, help will be easier to provide once you are dealing with actual issues rather than rhetorical concepts.

I think you are suffering from an overly simplistic idea of how things work regarding UVs. You must have UVs to apply a 2D texture to any standard polygon-based 3D model (we are ignoring voxel and poly-painting techniques which require high polygon resolutions, and are technically part of the geometry itself). SketchUp creates UVs (as it must) -- it just does not do a particularly efficient job with them, nor does it allow the user direct control of UV space. SketchUp also can support models which have UVs externally unwrapped (via plugin), however it can sometimes cause a big slowdown in SketchUp performance, and bloat SketchUp file size.

Substance Designers Tri-planar projection can resolve seam issues regarding how your model UVs are set up, but it does not UV unwrap your model for you. What this is doing is using the existing UVs to bake World Space Position and Normal Maps (2D textures), which are used to eliminate seam issues. But the UV's still must be in place to bake the 2D texture in the first place.

Now due to the seam compensating nature of Tri-planar projection, SketchUp default UVs may be workable in some instances. You will most likely find SketchUp UVs will result in resolution issues (and other possible issues). Part of unwrapping a model is about packing the UVs in such a way as to make efficient use of the texture resolution. But you may be able to at least bypass the seams as an issue using Tri-planar projection. SketchUp does odd things sometimes, and just because something can work in one instance does not mean it will always work in every instance.

That is assuming you can export your model in a format that Substance Designer can bake from without issues. Substance Designer will not make any changes to your model, so the idea that you can use it for any modeling operations (including UV layout) is fruitless. It is a one way export from your package to SD. You will only be bringing the 2D/texture portion of the Substance back to SketchUp/Thea.

So what I am basically saying is you are going to have to resolve yourself to setting up your UVs before you go to SD -- whether that be inside SketchUp or otherwise (some Ruby plugins might be helpful here). Substances do not free you from worrying about UVs, in fact the opposite is true. At the very least you will need to use some of the UV helper ruby plugins, and will most likely need to use an external UV unwrapper at least part of the time.

Frankly I am getting a bit tired of playing with "what-ifs" -- you are just going to have to use the software's together and work out for yourself whether this pairing can become a usable workflow for you or not. Nobody else can answer that for you because only you know how far you are willing to go to make it work. The only thing I can say for sure is: compared to more robust modeling packages you will definitely find a SketchUp based workflow to be problematic. So you will need to be willing to potentially put up with alot of workarounds/plugins to find a usable workflow. Which is not true in the Substance supported modeling packages, where the workflow is straightforward.

Yes, the new tri-planar projection negated the need for unwrapping UVs in some cases -- perhaps enough to simplify a SketchUp workflow.

I cannot say enough good things about Allegorithmic -- I don't get the chance to use their products as much as I would like, just because my work keeps me stretched pretty thin (software-wise). But in dealing with various software companies I never see the type of laziness at Allegorithmic that most others display... these guys are serious about continually pushing the envelope. Frankly they are an exciting bunch.

In addition -- to clarify what a Substance is:

It is simply a collection of image editing commands (XML based) that are dynamically performed on raw base imagery. The base imagery can be Vector (in the form of SVG), Procedural (internal to the Substance Engine) or Bitmap (either imported or baked from the geometry)... or any combination thereof.

When you as a user see the various Substance altering sliders in something like Thea, what you are really seeing is certain portions of the image editing command chain that have been "exposed" to the end-user.

Substance Designer is the full authoring package for Substances -- with it you can import or create base imagery, set up image editing command chains (via nodes), and choose what you want exposed to the end-user of your Substances.

Substance Painter will allow you to paint directly on your mesh (a very ZBrush-like experience) using Substances (basic Substances can be created inside Painter, but usually you would create more complex effects in SD). These can be applied in a typical layering workflow with standard brush types, or particle simulations. Substance Designer is not required, and awesome work can be done in Painter without it... mostly because there are already tons of existing Substances you can use, and more to come.

Allegorithmic is the company making all of this. They are a dynamic, fast paced company that IMO always pushes forward toward new ground. I bought my first license for Substance Designer back in version 1 when it was nearly twice as much as the current pro pricing -- and I considered it to be a great deal even then. They have not disappointed me in any way -- I highly recommend their products if the type of work you are doing fits what they designed the tools for. Their main target market is video game creation, where the nature of Substances can give many advantages to streamline in-game user driven texture customization, and reduce bandwidth consumption.

To use a SketchUp analogy -- Substances are similar to Dynamic Components/Ruby Scripting... but with textures instead of geometry.

Edge effects are all controlled by geometry baked textures, so resolution would be an issue for larger models and UVs will become an issue if not properly handled. That is also assuming the SketchUp created geometry is intelligable to SD/SP... which could be the fault of the model creator or SketchUp itself.

To answer the resolution question, in some cases it is possible to go higher. You definately want to do the bulk of the work at lower resolutions, but a lot of the best features of Substances come through geometry-baked textures as the base... baking those textures can be resource intensive at larger resolutions.

Substances make alot more sense for character and prop models based on subD which have high poly sculpts (ZBrush or similar) to pull geometry-based information from. SketchUp models are usually so basic that the best features of Substances really will be marginalized. And that is before you even have to deal with UV unwrap and seam issues.

Substances are geard toward next gen (sculpt heavy) wokflows being developed by vidogame companies. SubD modeling and great UVs are the basis of how these projects need to be done to see maximum results.

Certainly, this is why I specified video game work. For ArchViz work Substances are still not very well suited (and may never become so)-- the biggest boundaries existing with texture rendering resolution. For Substances to render very large textures (and rendering still images requires larger textures than moving images) you need a top of the line video card or the Substance workflow is very sluggish.

Two very different workflow priorities -- and, as I said, they are not compatible.

For the types of effect you want to achieve it is all reliant on great (not just "good", you need great) UV unwrapping -- which is something I pushed for with SketchUp for a long time, but ultimately realized was fruitless. For this, and a couple of other good reasons, if Substances are a part of your workflow (and as time goes on it becomes more and more clear they should be for any type of video game work) SketchUp should not be.

The bottom line is Allegorithmic is a company that is always pushing the technical limitations, and SketchUp is a software firmly stuck in the technology of over a decade ago -- the two are not compatible. My best advice is to move to an modeling application that already fully supports Substance integration like Modo, Maya or 3DS Max. Time (and money) spent learning the new software will ultimately save time (and money) as compared to suffering through a tortured and broken SketchUp-based workflow.

You certainly get the benefit of higher binned componnents, but the downside is they tend to be a generation behind. I've seen people try to hack the older gamer hardware with the workstation drivers to get the same results(for less money).

The proven stability of the components combined with drivers geared for the openGL task and better support are what you pay for. Gamers get irritated about these types of cards because they are not gamer freindly, but I don't game so I don't care.

Multicore support might add some speed in certain specific operations, however it is not the major bottleneck to general SketchUp performance.

The major bottleneck has always been the realtime OpenGL render engine that is always running (what we might think of as the SketchUp viewport). The complexity of that rendering is (mostly) controlled by the current Style that is applied, and depending on the simplicity of the Style used you can see massive performance increases while working in SketchUp. So if you are looking for more "juice" from SketchUp I would invest some time in creating a few super simple custom styles to use while modeling.

It is also worth mentioning that using a pro-level workstation class video card (Quadro or FirePro) will always increase performance (and visual quality) more than just about anything else (hardware-wise).

As for the purpose of 64-bit, the advantage is not meant for SketchUp per se -- but rather for the 3rd-party plugins that work inside SketchUp. Particularly render engines which are RAM hungry. That said, from Trimbles POV the real reason this was done is because Apple required all Mac compatible software to be native 64-bit by a certain date... so they didn't have much choice.

You keep wanting to make this about social ills... but I don't think you are getting the simplicity of the issue. The issue here is piracy of SketchUp... or in a more general sense software piracy. You act as if I am not aware of the larger world and what goes on out there... but that assumption is based on the fact that you:

a) know next to nothing about me.
b) are attempting to argue something that is not relevant to the thread.

For instance you keep talking about the evils of white america, as if I have no understanding of this. What you don't know is my great grandfather was forcefully taken from his family on the reservation, and raised in an orphanage as "white"... this was part of an effort to erradicate the tribe. There are are other similar issues, but that is my personal business... so I won't elaborate further.

Similarly, what I am adressing is the need to pirate... not the morality of doing so. You are attempting to pull me into some sort of stance on the morality of such, but I have only commented on the hard practical realities of the situation. It is not needful for anybody to pirate software in todays world... open source software has become so prevelant that almost anything you need is there for you.

You attempt to use "cultural ignorance" as some sort of catch-all protection from personal responsibility, but I would suggest anybody capable of finding this place is already well informed enough to know the expectations involved.

Furthermore, the original poster is creating video game assets... I wonder what his stance will be when the time comes for his product to be pirated.

Best,
Jason.

The old "I am not as bad as they are, therefore my bad behavior is excusable" arguement... my issue with that is very practical:

To pirate requires you to go out of your way, to potentially dangerous areas (Virus-wise), to obtain the software. Whereas downloading, installing and using an open source software is safe, easy and always encouraged.

If you take the approach that piracy is giving the finger to corporate america, then I would suggest that using the open source software, and contributing to the growth of the marketshare of those (versus the corporate softwares), would be far more effective.

There is no downside to using open source instead, other than having to momentarily step outside the familiar routine... but that is a wise investment of time, which will serve towards giving long term freedom from corporate powers.

Best,
Jason.