Well not really what I mean. What I mean mostly has to do with the video game industry and how it’s evolved.
Basically, now a days, you buy a game which is released prematurely(incomplete), and over time the game will be updated.
At the end of a 5 yr period, a user might have to do hundreds of gigabytes of updates and the game will be extremely improved and contain vast amounts of content more than the initial release.
So, the point here is mostly about the ability for “software” to be updated over time – post release.
So you “shipped” 33 “service releases”/3yrs, 2500 bug fixes etc., so my question would be how many gigabytes of data is the initial release? and how many gigabytes of data in “updates” were there in 3 yrs?
So it sounds like we need to add 500MB of textures with each service release? Soon we will have 200GB of additional bulk, and it will be worth the price of the upgrade?
I’m kidding - it seems like the metric based on file size is really appropriate for video game content, but not so much when you’re making the content. I’m guessing that ShrinkWrap added less than 20MB to the size of Rhino, which by the bulk metric above means we should probably just leave it out.
The bug fixes might only add a few KB. And in many cases, we actually make Rhino smaller by removing code that doesn’t work.
To echo Helvetosaur, we really only want you to buy Rhino when there’s something in it that you value, need, and are delighted to pay for. If Rhino 8 doesn’t have that, please keep your money.
We can’t prioritize everything for everyone all the time. So the things we prioritize will delight some and disappoint others. That’s just a reality. I’m sorry to those who get disappointed over and over and over again.
Honestly, comparing the folders between the two you start appreciating the work being done
Ccycles, , Openvdb and pythonnet are part of the new features. so, no complaints.
Although my boss won’t be easily convinced to upgrade our company licenses (not much for Architects who use PC devices), I’m going to upgrade on Day 1, just to have the exclusive feature of ability to be involved with V9 Serengeti.
I was using the video game industry as an extreme contrast, is all. Please don’t take out shrinkwrap
I understand video games probably have tons of texture bulk as you mentioned.
I’m mostly intrigued by the industries new strategy to add the content to a game, way after the initial release, and often times charge their customers for the content – which actually should have come with the game from the very start.
So, it’s interesting that such software can even be modified in such a way so many months or years after the initial release.
I see it as a potential powerful solution to the dichotomies between different versions. Instead their can be more of a blend.
Like why can’t V7 have shrinkwrap? And if Eto Framworks are a thing, then where’s the explosion of all the frameworks? I thought it would open the floodgates. Whose keeping the floodgates closed I wonder. How long till the dam breaks. jk, maybe I’ll know more when V8 is released.
oh nice! That’s cool, I appreciate the insight I like visuals.
This is really cool, and I’m not sure what it is yet like super fancy heat maps
Adding new features is a double-edged sword. Adding features also often causes major problems and bugs. Some features bolt in easily and don’t affect a lot of other features (for example, adding a new file type to read or write). Other features disrupt major amounts of the core (adding SubD).
While we could do all this work in an existing version, it’d likely break a lot of stuff that people relied on for weeks, months, or years, during development. That seems like a pretty rude thing to do to people who already paid for the software and just want to get their work done.
On the other hand, doing new things in new versions gives us the flexibility to make mistakes, make changes, iterate, and find ways of making new features consistent with the older ones, without doing so much damage when the product is finally released.
The game industry is interesting; I don’t know how it works at all.
You’re comparing to software that basically doesn’t have versions; they just have a single line of development and release new or fixed things in that line.
If you prefer that to McNeel’s Rhino model, then you’re probably either asking for a subscription model or one in which the new user revenue subsidizes development for earlier purchasers indefinitely.
Either can be viable, but the CAD market has users that stick around for decades. If you only charge the new users, then there’s a lot less money available for development: just look at the incoming revenue stream if noone is paying upgrade fees.
Is one of those two things, or a hybrid, really what you want?
(neutral question, I’m personally not opposed to a subscription model so long as there isn’t a fear of suddenly not being able to access old files if Rhino were to be discontinued)
Maybe true. The gaming industry basically forces the updates upon users, and yes they break things and cause bugs. But they also fix them as a natural reaction to the problem.
One thing they don’t seem to do, inherently due to forcing all users to have fair results, is give the option to use any permutation at any time. For this the gaming industry would be a bad example.
So, to address the super professional CAD industry, you could enable users to access particular states they could download, and have lists of their known issues.
If adding shrinkwrap to V7 version-xyz causes problems or bugs, then users can decide to update or not, or revert back to a previous permutation that is more stable. You could also fix the bugs over time in this manner due to giving users access to the potential backup stable versions of this process.
If adding SubD disrupts major amounts of core, then users could have access to different versions/permutations over time and always have the option to revert back to more stable versions without SubD, if they want to – while the fixing of bugs continues, and more stable versions become available.
This could add more flexibility than you have now. Damage is relative. If users have access to backup versions without the damage, then what would be the big deal…
Yeah, I’ve kinda neglected to mention that issue. I suppose the upgrades should always have a cost value, and users would have to buy them.
Obviously, Rhino has ultimate control over these decisions, and yes it can be a huge can o’ worms.
I’m still blown away by the very stable price point throughout history of Rhino being very affordable and the upgrades being very reasonable too. So, I’m not trying to criticize anything there.
Maybe, I’m just wondering if there could be more upgrades more often, and have the obvious fees etc.
Idk, it might get outa hand and maybe I’m not making much sense. It’s the caffeine talking
Keeping with your game industry comparison, the only things I can come up with for a fee analogy is playing on a premium server (CAD has no real equivalent unless they started charging for forum access and better samples/docs) and buying expansion packs (which would IMO be confusing and annoying for engineering type customers who would probably immediately ask what the fee was to simply be current without having to micromanage expansion packs).
I could be wrong about the market base, but I expect that most customers are relatively conservative business types who want an easy to plan for business model, not expansion packs aka modular components resulting in problems from various customers opting in or not for various features and then trying to work together.
Given the current cadence of upgrades, a Rhino upgrade costs you about U$0.70 per workday. I think it’s worth supporting an independent 3D company at that price regardless of what you think of how targeted to your needs is each upgrade.
No other company on this industry is this accessible/affordable. Except for Blender of course. But I rather had a paid version of Blender for 2X the price of Rhino, if it could give you at least half the level of McNeel’s support.
For what it’s worth, I’ve been using Rhino 8 WIP for the this year for my architecture thesis. Had exactly one problem where I had to look up what they changed and alter my workflow.
Using Rhino 7 at the office, and I’ve had two crashes this week already. It’s Tuesday.
– how laggy is v8 currently on Mac
– how buggy is Metal currently performing
– how messy and poorly designed is the new UI
I’m perceiving v7 → v8 as a serious downgrade.
If v8 will be released as immature as it is the product now (and it will be), I am considering to stick with v7 even if it’s not Apple Silicon ready – and I am on a M1 Pro mac.
You can also report these bugs and lags. If a serious bug is discovered, the priority of this bug is placed under “Stop-ship” which means they can’t ship V8 without this bug is resolved. Many of us here are testing V8 daily to make sure it won’t be a bad release. Look how dedicated people are here.
I’m testing on the PC side and in daily communication with the mcneel developers and it seems they are listening and communicating very effectively.
I have reported dozens of bugs, and none of them are resolved.
There are tons of small errors or UI mistakes that make v8 unusable on a daily and professional basis, and McNeel isn’t listening.
Even Metal is unusable! I mean, you can’t even model in standard Shaded mode without becoming epileptic.
I wonder where the others Mac users are?!
That’s cool, I appreciate the insight 
I like visuals.
This is really cool, and I’m not sure what it is yet 
like super fancy heat maps 
