SubD-Project: reasons for editing the Limit Surface?

In recent discussions I learned that McNeel plans to implement their Subdivision Surfaces workspace different from the way comparable toolsets are set up in popular SubD applications, such as Modo, Maya, Cinema4D and the like. Instead of offering Subdivision Levels which give a mesh based approximation of the Limit Surface one lets users shape the limit surface directly.
This document gives some more detail. I understand that the goal is to offer import/export compatibility with applications which use a mesh based approach – but I’d really like to understand why McNeel took this decision in the first place.

Where do you see key advantages of taking this route?

I guess we didn’t see any need for rough approximations when we can quickly calculate the limit surface.

I understand that mesh-base sub-d modelers use levels to limit the number of facets. With our approach you can still limit the number of facets, but they will be calculated directly from the spline-based limit surface rather than a mesh subdivision level.

Of course, we will provide many tools for refining and editing the control net (level 0) either by directly editing the control net or the limit surface… much like you can with NURBS surfaces.

This might not be exactly technically correct, but @dalelear can correct me if needed.

Thanks for your answer Bob,
to be honest I was afraid to get an answer along these lines. Using the more accurate option of two seems like the obvious choice for an implementation inside a precision modelling application like Rhino!

I’m just not sure if you guys are fully aware about the sheer, massive amount of plug and play features and cross-application workflows one could essentially “harvest” by utilizing a mesh based SubD approach instead. Many applications may interchange geometry via clipboard and all relevant information travels along, UV’s materials, Grouping etc… a second later the model appears in the target program, without conversion, without any fuzz.
The whole digital entertainment industry today is mesh based all the way: There simply have to be pretty good reasons for firms like Autodesk, The Foundry or Maxon – who all employ real big brains too – to stick to meshes. Using mesh approximated Subdivision Surfaces meant that one had most, if not all of this working in Rhino too, in earliest implementations already. Using the Limit Surface approach means that nothing will “just work”.

There sure were conversion options from mesh and back to mesh – but you’ll agree that conversion always means a source of error and developer time spent for implementation and maintainance. And why converting in the first place? Todays mesh approximations have superb performance at multimillion faces level and could especially in clever conjunction with Nurbs methods match any precision and smoothness level for industrial manufacturing.

As this is such a fundamental decision which hardly can get reverted later I would really love to see various real world modelling examples which give good evidence of advantages over mesh based subdivision surfaces in conjunction with Nurbs. I’m sure, that this would help you too.

1 Like

I don’t get it. The sub-d level 0 geometry is basically a mesh, just like it is a mesh in any other subd modeler. It can have attributes on vertices and edges to affect the subd shape, just like in any other subd modeler. As far as I can tell, the difference between taking a mesh-based approach and a limit-surface approach is how you calculate the shape people see on the screen. There are only three reasons why anyone (besides the programmers) would care about the underlying algorithm:

  • Performance. It is too slow to work with?
  • Correctness. Is the result actually what people expect?
  • Consistency. Is the result the same as you would get elsewhere?

As for correctness, it is true that our approach does not let you compute the intermediate stages of a subdivided mesh. But does anyone really want to be able to generate a not-quite-correct subd if you can get a correct one for the same price? I can’t see why, but I might well be wrong.

As for consistency, that’s a lost battle either way. Some modellers use mesh-based subdivision and our geometry will differ (a lot for coarse subdivision levels, a little for fine subdivision levels) from those. On the other hand Pixar has released an open source SubD library which uses limit surfaces, so we can either be consistent with group A or we can be consistent with group B.

I don’t see a reason why you couldn’t exchange subd shapes between Rhino and other apps, be it via files on disk or data on the clipboard.

1 Like

AFAIK none of those companies have the know-how to make fast performance of mesh-to-limit surface calculations. Let alone trying to have clean/accurate results in the conversion. Maybe the McNeels got so confused believing the marketing copy and demo videos of those companies that ended up working harder at the problem and they might be the only one that have something that doesn’t suck? They got duped! …Or maybe they have bigger brains :wink:

Hi David,
to me opting for the Limit Surface approach to me builds on various assumptions I do not share.

  1. Working on the limit surface will make finished models more accurate and overall useful than using mesh aproximations.

  2. Automatic conversions to Nurbs Polysurfaces from Limit Surface is a highly attractive output goal for SubD users.

  3. Working on the Limit Surface generally simplifies the modelling process.

  4. With the Limit Surface approach one can serve technical customers specific needs and yet be fully Import/Export compatible to mesh approximated subdivision.

I will comment on all of this later today.

Hi Holger,

I find it ironic that apparently goZ is not able to make sure the hand model is oriented as it was exported. (at 1:35 note how the hand that gets send back is now oriented flat) That IMO is far from without any fuzz.

Aside from this slightly sarcastic remark, let me show my point of view for the subD approach of Rhino:

Working with meshes is only relevant for geometry that need to be visually smooth and appealing. There is no such a thing as true smoothness for meshes. They are and always remain faceted representations of a surface boundary.

What will not work when they are mesh based is pretty much all Rhino tools operating on nurbs-surfaces. No tools that need NURBS as input will work, this involves many, many tools in Rhino and as such the subD feature is mainly usefull for standalone organic shapes without intergations into Rhino’s core feature set build around NURBS modeling.

Exactly! So having a NURBS as initial output will give us the most exact represenation possible. And as Bob suggested there is always tools to export the lower divided sudD.

So why go for the multi-million faces route if a lighter weight NURBS model is more efficient and theoretically an infinite/unlimited lever of accuracy. As for the industrial manufacturing, you are correct but it’s the route towards the manufacturing that needs a way to do math with the geometry that is not possible with a mesh. The manufacturing industry avoids using meshes to model, they use highly accurate representation of the geometry and only in a final stage convert to meshes if there is no other option.

Is that not what McNeel is doing? Make a NURBS based subD approach offering exact surface approximation where others find themself making multi-millions of faces trying to get close.

This model I made with V6 was my first venture into subD modeling.
It was great to be able to manipulate the shape via subD modeling and have history based intersections that I could analyze for curvature. I could analyze surface deviations from given geometry and have an accurate set of surfaces for further modeling in other industrial CAD applications.

What I fail to understand is what it is you would like to see different. I’m probably missing the point not being familiar with subD implementations on other software. What would you like to see different than editing the Limit Surface? Is it not so that the difference is that you would like to have a mesh representation of the surface where McNeel implemented an option to have both NURBS and MESH output? I see no mention there is no way to output meshes at any level of subdivision.

I’m new to subD editing and as such would like to know where you are coming from and what you would like to see possible in Rhino.


@1) “Working on the limit surface will make finished models generally more accurate and useful than using mesh aproximations”.

My short answer is: Forget about accuracy, Subdivision Surfaces suck in that respect anyway :o)

People here in this forum typically just rave about Subdivision Surfaces, but that paradigm (as also Nurbs) comes with some real bad limitations one has to acknowledge. While wonderful and straightforward for fleshing out swoopy overall workpiece volumes SubD in all software implementations I know has poor usability for accurate detailing of models. Already cutting a simple circular hole into a bulged surface (such as the one Willem has has posted today), while maintaining the overall curvature is a major challenge, users are forced to develop a good understanding of quad mesh topology, one needs to plan in advance + has to count faces before even starting with a model: Even a silly starfish can only get modelled from a cylinder with an appropriate count of radial faces.
Efforts neccesary to acomplish mechanically formed stuff, which is super straightforward to do in Nurbs is hard to stand watching at times. Pretty quickly the loose cage can transform into a tight corset! In order to avoid laborious mesh reconstruction it is pretty common in the mesh world to let entities simply intersect, which of course hardly made sense for models,supposed to be technically valid. Namely shortcomings led to interesting products like TheFoundy’s MeshFusion: This plugin for Modo allows fusing several SubD input shapes together via Boolean Operations, generates a new, quad dominant mesh with editable intersection areas and maintains all input meshes live-editable. Another popular route users take is to add complex surface detailing using High Res Sculpting in either Mesh or Voxels and to automatically (via e.g. Zremesher) or manually reverse engineeer a logical SubD mesh on top of the input volume.These techniquese are mostly used by people in the Entertainment Industry who merely want complex, plausible looking parts, which however have not to serve real world purposes and haven’t been constructed with a technical mindset in the first place.
One today generally can not built complex parts which fulfill serious industrial manufacturing constraints (draft angles, equal wall thicknesses, fitting tolerances etc.) by using Subdivision Surfaces techniques alone. Not in CATIA Imagine and Shape, not in Tsplines or Autodesk Fusion, not in Modo, nowhere. Using mesh aproximation or Limit Surfaces makes no difference in terms of constraints of the paradigm one will encounter.

1b) Using HiRes mesh aproximations in SubD in my perception on any practically relavant level disolves the difference between facetted meshes and the mathemathical Ideal. Typical Mesh aproximated subdivision surface models may hold the detail of skin pores in a human face. One would need just a fraction of that geometry to represent arbitrary technical models at the required accuracy level for any output goal. I’m saying that what I have seen in mesh aproximation should be plenty good enough for anyone and any machining task. As a bonus mesh aproximated SubD brings loads of highly attractive features with it, for free.

I am thinking of a pragmatic Nurbs supported but mesh based SubD implementation, where meshes through means of dense subdivision and projection may be brought into any shape, may be made smooth and continous to all technically meaningful levels. Overall I see the development of complex freeform shapes as an iterative process where Nurbs and SubD in conjunction with the the new Quad mesher complement each other. In this collaboration I see SubD tools as the loose and playful Volume Builder and Nurbs entities, such as curves and surfaces as the Accuracy Provider, Refiner and and Detail Maker. What I don’t see currently is making serious precision parts from start to end by using SubD methods alone.

*@2) “Automatic conversions to Nurbs Polysurfaces from Limit Surface is a highly attractive goal.”

I see that some users ask for this option for compatibility, as their CNC toolpath generator* is stricly Nurbs based and accepts no meshes. Hence one maybe shouldn’t entirely come around offering something along these lines – especially as a micacle nimbus ships along with Auto-Conversion.

But apart from making geometry half way readable for certain software products* what’s the actual technical value of this conversion? One turns a perfectly editable (but likely inacurarate mesh) into a valid, smooth but equally inaccurate Nurbs polysurface which no more allow for the slightest refinement by using surfacing methods, at least not without laborious manual reconstruction of the patch layout. I found more useful when someone started converting SubD- meshes or parts of those into human editable Nurbs surfaces, which possible aren’t trimmed and joined but which indeed are proper raw material for further nurbal editing. Attached is the auto-conversion result of the mesh I posted recently. It looks better than I expected, but I wouldn’t want to edit this model.

*which of course will immediately reconvert the Nurbs model to a mesh again…

@3) Working on the Limit Surface generally simplifies the modelling process.
(one part of this, according to McNeel is that one abolishes the concept of Subdivision Levels)

My take on SubD Levels: Any of the aproximation steps or SubD levels has its perfect use when freely developing a shape. Not having them available in Tsplines has always sucked, Clayoo made the same mistake and now McNeel is about to follow. If one considered SubD-Levels worthless in typical SubD apps one would sure skip them and jack the resolution up to some multi-million faces level right away, no?
To describe that specific quality is not particularly easy though… Let’s try it this way: Users in SubD modelling needs to develop an understanding to what shape the mesh will converge at higher levels. One at any point in the SubD-modelling process needs to obey some fundamental topology rules, SubD levels here help chasing down issues and re-flowing loops of faces if need be. Triangles may cause problems, Ngons on non flat areas will as well. In smoothed state faces may shrink or fatten and even hide triangles and Ngons, edge loops at tight transitions aren’t even selectable any more as that closely together or partially occluded – here one needs the lower SubD levels to losen the tension, to get access. On the other hand the Level 0 cage may look all messed up and entwined, but still converge into a valid smooth structure. Here editing the cage at a somewhat higher display density will be more helpful. In Tsplines or the like one has to obey the same rules as in mesh based SubD but the display options given make editing a lot harder. Let me know if this is understandable, otherwise I could try to record some gifs.

SubD levels also give simplest possible access to a proxy display for complex items. Stuff one currently doesn’t work on can get displayed somewhat coarser for realtime display but still may get sent to renderers at higher SubD levels. As Tsplines had permanent complaints about performance one btw. at some point added – not SubD-Levels – but an option to control the density of the (secondary) display mesh for their limit surface (which as a creamtopping doesn’t even use Rhino mesh setting location). Pretty unelegant.
Using a single mesh as both the work geometry as also the shading instrument is the simpler principle and proven for about two decades. Mesh based Subdivision Surfaces when hooked up right really may have all attractive properties of a young dog: Fast fun, playful, a bit silly maybe, but robust.

This approach to me was the ideal counterpart to the in comparison somewhat grave “let me see what we have here” horlogists approach required in certain Nurbs surfacing scenarios. Thus far there simply was no implementation of SubD in Nurbs and derivates which could convince me. Everything feels as if one had poored a glass of honey over a mesh – and slower software is never simpler.

@4) With the Limit Surface approach one can serve technical customers specific needs and yet be fully Import/Export compatible to mesh approximated Subdivision.

I’ll concentrate on the areas where one likely that one will run into issues with the Limit-Surface approach:

UV’s: Imported meshes may come with one or more UV sets /UDIM Tiles and a stack of bespoke textures assigned, which upon transfer to Limit Surfaces will no more properly fit. Both 3D mesh and the UV mesh will differ from the source. One will run into visible seams, bleeding etc. Whatever one did about this, one needed to keep the UV’s at SubD Level 0 untouched, otherwise they were no more usable when sent back to the source app. I have no answer what needed to happen when one did some edits inside Rhino but wanted to keep the UVs.

Grouping: Imported meshes may have Subobject grouping (Vert, Edge, Face) – one needed to transfer these entities into something exclusive to Rhino. On re-export to mesh applications one had re-establish these groups again into a meaningful format for mesh modelling programs.

Possible support for advanced concepts: Using purely mesh based methods it was likely easier to natively or via plugin support concepts found in VFX apps like Hair, or animation + all sorts of baked into geometry effects. I’m not keen on such, just saying…

Resolution borders:There will be a resolution range on imported meshes which one will no more be able to subdivide to limit surfaces (some 100.000 faces) but which in rendering wouldn’t look smooth enough. With mesh based subdivision one had nice control about viewport and render resolution.

Creases. But these are a problem everywhere.

Hi Hifred, Im deeply interested in this thread as I am a 10 Years SubD Modeller using AD product. to be honest I dont know how Mcneel will introduce SubD in the next release, but IMO They should consider not to go too far away from industry standard SubD that has been proven successful in visual graphic. I just want to add my 2 cents, the beauty of SubD is that it is a super simple geometry, so simple in fact that u can push poly count to billion if you have a descent set up. so simple in fact that it can be manipulated with deformers (maya) or Modifier (Max), so simple in fact that its information (vertex position, normal) can be transfered - blended or even multiplied to other geometry without regards of topology. T-spline fails to maintain simplicity of geometry which leads to performance issue.

what I would love to see in Rhino SubD project is not just having “traditional” subD operation (edge loops, cuts, etc etc )
instead introducing a modern tool to work with SubD. an old style subD is always =model in a low mesh and once you are done, subdivide and boolean till u please.

new SubD tool in other Apps now has the ability to modify a highly densed mesh. with robust free form deformers (or space warp / modifier in Max), blending between multiple mesh, MeshFusion (oh I love it) robust retopologizing. and full history support for all command. ( in Maya I can create a NURBS surface, trim it with Curve, Convert to SubD, Modify SubD, and I can still go back to edit my profile curve used for trimmming, and the change will propagate through my SubD.) this is where I can combine both NURBS and poly workflow.

It would take a couple of version for Rhino to go to this step but I believe if Mcneel team sticks with Industry standard SubD, it would be easier for other user from other app to adapt to rhino. (and also exchange file)

as for precision, instead of trying to make SubD model works as precise as NURBS, ( which I think would be hard to achieve ) its better to have a simple conversion of SubD to NURBS. I have been thinking about a way, we have a tool normally to easily “cut” subD model to “patches” for UV purpose, the process is actually so simple just defining edges where you want the seam to be, once done, a simple algoritm will have no trouble to convert each patches into NURBS 4 sided patches.

as for the common misconception about subD model does not have enough resolution to render a smooth curvature, some renderer engine provides render time tesselation.

and these are mainly for visual graphic, if one needs a SubD model for 3D printing, then Zbrush billion pixol would seem to be the only solution.

I use subD mainly for form finding, and like AD product that focus on SubD, the reason is because of easy tweaking. so hopefully mcneel need to look at a perspetive of a “designer” when developing tools for SUbD.

I actually wanted to talk about Wacom as well, but I always get a harsh reply from Rhino user when I mention Wacom in my post.

anyway, perhaps I am a little bit off topic here, but i am excited about Rhino SubD Project. and, Hifred, I love your detailed explanation… :smile:

thanks for reading

Ho Holger,
You put an impressive amount of time and effort on this subject, but I have to say that I don’t relate to any of the point you make.
I don’t use “industry standard SubD” becouse it doesn’t fit my need and the kind of project I do.
New tools that will expand Rhino’s power, and blend with the current toolset, are what will benefit my work.

correct me if Im wrong but I think what Hifred wants to point out is the mesh-based subD approach gives more control to work on Multi-level SubD, which is crucial in poly-modelling workflow.

I found not so many people are interested in having proper SubD tool in Rhino, which is not a big surprise, one who has been using NURBS for their entire work will likely try to force everything in NURBS paradigm even when working with Meshes, while a poly-modeller will think more of a mesh topology, tweaking, and refining shape as we develop the model.

the main conflict comes when we have to work using both. the simplicity of SubD mesh, easy tweaking and accuracy of NURBS and underlying math behind it is what we all dream to have in a single software. to achieve that, it is safer to stick to what the industry standard has been using for decades of experiments and achievement.

I’d like to quote what my friend and mentor Horace Dediu says:

“Every time an expert complains a cash register rings.”


For sub-D topic, as long as mesh turns into Nurbs im satisfied…Unless people are expecting Rhinoceros can work like many polygon tools, producing CG characters…not sure if Rhinoceros can handle that many faces…

Runnie, lets be clear. You said you want to delete command bar using Wacom. That will not happen. You can have a party with wacom pen or tablet using Adobe, Zbrush and such but not for Rhinoceros. Why Wacom? reasons? the workflow? Can you give comprehensive reasons that why others have to follow this? What is the benefit of this? Please show me how you click CPs and move them; how you replace CPs make T, C continuity with that Wacom pen… Is that productive?

I feel that AD users want to make Rhinoceros like AD… Indeed, AD got really good features Rhinoceros could look into, but let’s not force. It sounds like you want to work with Nurbs tools like Zbursh, brushing nurbs surface using Wacom… another thing, I have a mouse that has 7 buttons (more buttons available), does Wacom provide that?

How about people who just started using Rhinoceros? Can everyone afford Wacom or willing to buy Wacom? Of course, for users, having same interface, same workflow is the best, but from company point of view, they are competitors… that will not happen. Like Apple VS Samsung…

hi kevJin, well actually I didnt mean to say “deleting” command bar and replace it with wacom. perhaps my english was too bad when I made that post long time ago, so pardon me for giving you guys some missunderstanding. what I meant was to have a feature of “hide” the current position of command bar and instead having a “floating command bar” that is close to the mouse cursor. and of course since that is just a feature, user can hide or unhide command bar whatever they like. I was thinking a floating command bar or even a pop up small window that has numerical input + sliders so u can see geometry changes in real time as you scrub the slider. and of course u can still type in numerical digit just like you do in command line.
but of course this is just a suggestion, I am not saying the current command bar is bad, I am just trying to give some idea.

and… I dont mean to tell mcneel to replace mouse with wacom, I was just suggesting to give some extra feature for wacom user. of course you cannot fully replace mouse functionality with wacom. ( like I have never seen anyone working on AUtoCad with wacom LOL )

if you ask what is the benefits of having wacom in rhino, I would say currently all rhino command works best using mouse, but why suddenly I bother to mention wacom is that when they consider to have wacom as part of the tool, it would add more possibilities for a new type of command that is not practical using mouse.

for example=
let say we have 3 prototype of design. Design 1, 2 ,and 3 they have totally different topology. and it is normal for designer to show a client several options, and most of the time they would say = "I like this top bits from design 1, but I like the overall silhouette of design 2 and probably we can get the same curvature flow like design 3.

with wacom there is a possibilities of blending those 3 characteristic with pen stroke, instead of making completely a new model. and we can see them changes artistically in the viewport. pen pressure controls the blending bias and stroke control which part you want to modify, simultaneously.

another advantage of course is sculpting NURBS surface, it is sometime useful when the model isnt really aligned on neither X Y or Z axis. of course you can still use move UVN but Wacom gives me a more artistic control over the fall off distance.

as for modifying continuity with Wacom, currently rhino wont allow me to change CP position without maintaining continuity. (unless V6 has a really good history chain) but there is a feature in other software (Maya) that can “lock” T continuity and let us adjust CP as we please. and surrounding CP will move respectively to compensate that.
to be honest this feature is kinda buggy even in Maya, since Maya NURBS is far behind Rhino, that is why I hope to see rhino handles this one in version 10 maybe :stuck_out_tongue:

I made a post long time ago in Grasshopper forum, some folks there even suggested in using Wacom to manipulate multiple sliders, or interactive creasing with pen stroke. but again of course it is possible to adjust each slider one by one with mouse.

there are tons of other stuff especially when you start to work with Mesh. but, having wacom is just like having “3D mouse” it is not for everyone, and it wont be the default setting for navigating in rhino, but at least having those as “feature” would not hurt anyone.

again, I dont want to make rhino looks like AD, or neither AD looks like rhino, each has their own strength… I just want to unify their workflow because most of design company nowadays use multiple software.

and one thing I like about RHino is that it is a tool for both builders and designer. especially grasshopper, I have seen critical design decision and form finding done in GH, and so many add on to support other type of file to be imported in GH. many creative architecture and design are done in Rhino or AD or even using both.

and I do apologize for causing a big misunderstanding in my previous post if that somehow offends anyone.

I still need to work on my english though, hopefully you can understand what I mean.

peace bro :stuck_out_tongue:

Those are more like features, nothing to do with Wacom imo…

I agree… I suggested this before…

Is this the feature comes with wacom? sounds more like Rhino feature. Some type of history…

AD Alias has this feature… This is not what Wacom does.

Still, nothing do to with Wacom. Surface/curve history features have implemented in V6. Not sure if they are fully developed…This should be Class-A modeling category.

Maybe, but I use Rhinoceros and it’s plug-ins to achieve architecture forms… you might think of Zaha hadid buildings, yes I can model all her models simply using Rhinoceros+Tsplines… maybe after sub-d becomes native in Rhinoceros, I only use Rhinoceros. So my point is, companies use many software, in terms of modeling, simply because diverse users and proficiency levels are different.

BTW, designers are not modelers…at least The Pritzker Prize winders don’t…

No wars, just stating what’s in mind… I speak broken english too…I’m a Korean/Chinese speaker, hard for me mixing up English as well… My mind is always peace, which usually comes after I speak out what I think… Either bad or good…

Not against wacom or 3D-connection, always good to have more features whether they are useful or not for certain people. In fact, what my intention was…

Always, there are steps Mcneel team has to take for each release. For V6, sub-D perhaps is the main focus. All wishes that time-consuming should throw backyard, focusing on one… Isolated mode. First, Mcneel doesn’t have enough developers; second, the strategy should focus on customer base imo… That will help Mcneel grow faster, and later on can have more projects(sweet features for us)

Leave AD come to Rhinoceros world LOL (JK)

1 Like

yep, I do agree those are only feature, and are capable executed in both Mouse and Wacom.
again i am not forcing MCneel or showing off that I have wacom, Im just suggesting… and I am no technical person so my suggestion comes from naive individual user. :stuck_out_tongue:

as for mouse vs wacom topic, I think we should just make a conclusion that both are a good tool and its up to the user to choose. it is a never ending talk like “which one is better Vray or MentalRay?”

yes, designers are not modellers, they are different of course, sadly, in my hometown and I believe this is also true in most country in asia where you cannot survive if you are a pure designer or modeller, jobs are getting harder to get and they hire person who has the capability of both.

and I do respect a diverse user from any software product, and I am very happy to know they are all open for suggestion.
its good to meet a person who knows their software well like you, and the rest of the user here in Mcneel forum.

and I do like Rhino3D alot, Fell in love with Grasshopper when I saw it first time (6 years ago?)
and I am not a pure AD user, I normally start my model in Rhino and then go jump back and forth from AD to rhino. to craft my design. (also because I dont have renderer engine installed in rhino)

I agree that Mcneel should focus on one main feature and actively hear the complains from customer.

by the way, to bring back the SubD topic, since I assume you are a hardcore T-spline user, maybe you can give some ideas from your experience :smile:

nice talking with you bro, keep the discussion going guys, sorry to interrupt this topic btw :smile:

1 Like


the word came to my mind…