Redacted
cridgit
Posts: 1,757
Whoops, all gone.
Post edited by cridgit on
You currently have no notifications.
Whoops, all gone.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Whoops, all gone.
Whoops, all gone.
A couple of quick comments from my first read-through -- I'll try to go through it more carefully later.
1) I don't like having a separate category for Earrings -- they should just be accessories for Ears. Similarly, Rings should just go under Hands, or if they must have their own category, then a category for Fingers would make more sense.
2) I don't think you should have separate categories for PZ2 or MC6 under Materials -- it should be irrelevant for the purposes of metadata whether the actual files are in a folder with .pz2's, .mc6's, or in a DS-format content folder.
Whoops, all gone.
Ah, okay, makes sense. I always install to dummy folders and only keep the sets I need, but you DO need some way to indicate the 'preferred' set if you keep them all.
I understand, If I want to change root category grouping much,it cause more problems.:)
(so I thinki it is better the root grouping is more strictly divided, obj and other files,
we can not talk about obj and many preset files at same time)
Now I think,, I can talk about how assigned files to the category which decided already,
or about new child category.
and my interesting is almost about wardrobe and accessory ,attachemet categorize.
they decide how my character look.
these items are in category about character appearance.
and the most important things for me to categorize wardlobes,
is how cordinate figure easily from many suitable choise.
in other word how cordinate and cover parts of body is first decided.
each innner parts>> outer parts>> then apply accessory.
my suggesiton.
Glove should be child of wardlove category.
if glove is accessory has sense in real life categorize, but I think it is better in wardlove category.
because I cordinate as body parts, first I set almost every item which coverd body.
Gloves has many type, but it covered most of hands and arms part.
I think accessory category should be small item and it can easily changing as you feel.
rings, bungles, or neck,,
but gloves decide about how your arms parts looks. if you change it, the looks
change significantly.
and it covered a most of hands or arms.
eg abiout game character, glove is one parts of costume.
of course the glove category need child category full arms or hands.
I want categorize how I can easily cordinate.:coolsmile:
and one more thing,,,
there is scene and sets category for each props .
I think everytime, why there is not full-set for wardlobe category?
that means it is category for full cordinate sets of the products.
if you click the pointer file, it load every items for cordinate figure of the products.
now we have sub sets files.so if vendor make the sub sets file for their products,
I think we can load it at once.
it is pity that I can not fit-to ore parent every items when I load sub sets now,
but I think it seems easy to auto-fit some items and parent items at once
by other preset files (or script).
so if bendor provide sub sets for all items, and for auto-fit files,
we wil categorize them in smart contents.
If I choose products sets and one click icon, which can load all items of the products,
it seems great,,,
edited
(now I find the way to make sub-sets with auto-fit!!)
Whoops, all gone.
Thank you ^^
then, I understand I can make category freely, but if every user change category as they like,
vendor products information and their categorize items,seems difficutl I think,,
(I hope, not so tweak meta-data or categorize by myself^^;
if the products was good categorized with rule,, and have right
meta-data,
and without no bug,,)
before I hope layer looked products series.
that need strict categorize and the category decide maybe basic size or length or thickness of the each item.
I hope if I choose one category, I can change more freely
without big poke through, that is like character making in 3D games.
I can freely change and choose items if I keep category,,
now if I change underwear,, it may cause big poke through,,,
so I think if user so many change category by himself, it can not decide
guide line for layer look,,
(though it is only one who hope the layer look costume series,,)
but I thought if vendor make each items in the size, with guideline of categorize for layer look products series,
if DAZ can make new line up,,,,:)
and I made many products full costume sets, today,,why I do not hink that before^^;
iti is so useful!!!
yes,, I make category 1 under the wardlobe, as you say! of course!
and 2 under the my category> fullset
(I made it by subsets,, but it is same as sciene,, in ds 4.5)
and make compatibility with genesis,, so I can find it so easy,,
next I made reference in the original product , and make new comatibility base
under the product base then declare it as fullsets,
it seems goes well , I can serch my full preset in "product" too,
but some case the file name disappear in content database editor. why?
I am a little scared so I removed reference from the products.:roll:
Redacted
sorry out of topic ^^; clear and delete image,,
I hope more people talk about meta-data ,how categorize is tbest for user.
==============
it seems better do not use this topic for my question,, (more important for another user
to talk about meta-data categorize,,)
I just stuck picture when the name has gone,,(before)
and change name and try again (once I closed ds,,) corrected
Hi Guys,
DAZ now has an official standard for metadata and we will be releasing all products, as well as updating current products to this standard. We would like the community to be aware of this and I will be uploading documentation this week for you. We have done extensive testing on the layout and categorizations and feel that this will allow us to put out metadata that is acceptable to most users. Those who wish to categorize differently in their own database will also have documents teaching them how to do this. Within the next day or so, I will be posting a link here for your reference. In the meantime, you can see the Categories and the Content Types here:
Default Categories
Content Types
I am sure there may be a few things we have forgotten or left off, and can add these in as needed, but after working for over a year to standardize this, we will not be changing the base format. We don't have the time or resources to change the store content multiple times. :) While I know these will not suit everyone, they have proven to be the most acceptable and intuitive to our test groups.
I will be glad to work with anyone doing metadata for the community. I have noticed several people working on things and we appreciate it. It is my goal to get the tutorial we have online ASAP (Thanks to one our community members for helping with this), and this will allow anyone to learn the ins and outs of Metadata and how and why things get set as they do. :) There are actually several technical reasons behind typing and categorizing content to ensure a well organized database and metadata that works. :)
As soon as I have the link live, I will post it in here. Thanks again for all your interest and help so far. It is very much appreciated.
Kat
This is very interesting news. Especially having official information and instructions available for everyone will help giving a better understanding why things are done the way they are.
- - -
Since the products are being updated I believe it is also very important that detailed instructions about those topics closely related to metadata are included:
- What is considered "User Data"?
- What is considered as the "Local Database"?
- What is considered as the "Product Database"?
- What is the exact functionality of the "Keep user data" checkbox that can now be found when importing metadata.
- Which data is saved in the local database and which in the product database.
- How are the "local database", "the product database" and the "User Data" linked together?
I have posted more detailed question in another thread that still have not been answered by anyone:
http://www.daz3d.com/forums/discussion/6123/#80081
A complete understanding of the process needs to be there to be able to answer questions like:
How is the checkbox "synch local and product database" in the content DB editor linked to the checkbox "Keep user Data" when new metadata is being imported.
Are there options to declare metadata on a product level as user data? Is there a toggle off or on switch somewhere on a product level that I can say keep the changes I made to this product put please replace the changes for that product with the new updates the DAZ team made?
- - -
Can someone of the DAZ metadata team please have a look at them to see if they are covered in the guide you plan to make available.
I hope you guide will cover this topics. If not I hope it can be updated to cover those questions.
Only if the community gets a a complete understanding how metadata is tied into DS4.5 it will be able to use it efficiently.
I'll make sure those get answered in the document. My team is working on the metadata updates, so I am involved in the whole process as well. :)
Kat
Whoops, all gone.
Whoops, all gone.
Exact definition of what EXACTLY the difference between "set" and "scene" are, would be helpful also. :-)
Whoops, all gone.
Cridgit,
Once again your work, dedication and feedback is invaluable!
I really really hope DAZ does still take the time to read, think and react to the very important suggestions, questions and remarks you made. I agree with most points and will comment just on those that I think need further thought and attention by the metadata and also the DS software team in general.
This cannot be stressed enough. The decisions that are made now will affect thousands (hopefully) of users in the future.
This post turned out longer than I thought. I hope you can find some useful suggestions as well.
I tried to give many examples and also suggest three new ways of being able to select folders in the different "Smart Content" and "Surfaces", "Paramter", "Shaping", "Light", "Camera" tabs to make full use of metadata categories.
- Ctrl Click and mark orange several subfolders so that all assets in those subfolder are shown.
- Alt click one folder to select only those files that are on the selected level but not show those that are in the subfolders.
- Shift Selecting several folders to create Average Quantity Selections that show only those assets that are placed in both categories and hide those contents of the selected folders that are only available in one of the selected.
I will also go on to suggest that the "Tag" system of the content DB editor is put into place to be able to search with tags.
As a bottom line all suggestions made about setting up the metadata system also have to take in consideration how the categorization is displayed and can be used in DS.
A huge distinction should be made between metadata as a folder structure in the different tabs and the way the metadata could be used as a search function in "Smart Content".
- - -
What the world really does not need are other "QWERTY" types of decisions that years later turn out to be rather uneffeciant but are kept being used because now it is to late to change it.
To give another expample for me it is complety not understandable how one ever had the insane idea to organize the poser library in a way that splits up a "Product" and puts the figure files in one folder three and the material files in another folder three.
Have you ever tried to find all material settings to Generation 4 clothing that were produced by different texture artists?
An easy task if you have only 10 Products and are starting out. Impossible when you have installed 1000+ products.
I stress this not to start a flame war because it shows a very different kind of organization that is featured in the DAZ studio library:
Thinking on a "Product" level.
All assets of a "Product" are kept together so you can quickly apply and remove them without having to change into a different top level folder.
In the DAZ studio library you can simply add a clothing item to the scene and then all material settings are conviniently to be found in a subfolder one level below.
To me this kind of thinking is what should help solve the rest of the categorization issues.
Do not ever split up files again that should be kept together.
Unless! and here comes one important characteristic of metadata:
One asset can be put into as many metadata categories that it fits.
If a chainmail shirt can be used as armor and as a shirt just make a checkmark in both categories.
Just remember the times when library cards where used to put the reference cards (metadata) into different sections while the book (DAZ studio library assets) stayed in one place.
Also another sore topic from me.
I am not a poser user and all those unwanted material options confuse me.
BUT I may be a carrara user in the future and may be greatful for any material options that are in the future included for both DS and Carrara. So what to do with them?
There should be some serious thought put into this. Again the solution may be with a "Tag" Filter system that lets the user show up only some material or file types. For example it should be easy to implement a function to just hide all .mc6 files in smart content and maybe as well in the DAZ studio library.
I think it would be unwise though to start a double categorization for all poser / carrara files.
I started to do that first. Dumping all poser material files into a /Materials/Poser folder but I later realized that because I was doing that I might never be able to share my metadata with other people because it might upset them if they actually want those poser materials in the same folder.
30. Where do we place vehicle or mechanical weapons e.g. fighter jet, submarine, tank, catapult, artillery? What would a suitable Weapons subcategory be?
As noted earlier things can be placed into different categories.
I started to use "Themes" for things like that.
Theme Combat with Area subfolders like Land, Air, Water, Space
or weapon type subfolders like Melee, Guns, Swords, Staves,
For example:
Themes/Combat/Area/Land
Themes/Combat/Weapons/Swords
Now again remember that things can be placed into more than one category.
Example Jetfighter:
Make one checkmark in Default/Transportation/Air and the other checkmark in /Themes/Combat/Area/Air
I had a good laugh when I read that one.
This was one of the first times when I filled bug reports last december about metdata.
In surfaces tab there were different categorizations named "The Fabricator" and there was "Fabricator" with subcategories.
Back then I wrote quite a long rant about how important it is to think of addon products and how they will be implemented in the future.
Should all fabricator addons be added into a subfolder of fabricator?
Will later users still know what "The Fabricator" is when they buy a shader product and will they know to look in a subfolder there or will they just search for the shader product name and not think to look in a "Fabricator" subfolder?
What the metadata team ended up doing was at first to add all addons as subfolder to the fabricator but then later on stopped and added them as separate folders.
So thats the result now: A mix between both instead of either or.
I guess this is a fitting last example. It is not enough to just look at the product in question. It is very important to keep in mind past products and future addons. Does it all fit together nicely?
- - -
In short
There should be made more effort of actually using the ability of metadata that it is a reference that can be placed into different categories.
Implementing the Tag System of the Content DB Editor can give the option to search for assets that fit different categories.
Implementing keyboard shortcuts like Ctrl, Alt and Shift can give the option to display the contents of several, just one or an Average Quantity Selection of categorization folders.
It is very imortant that now it is deceided once and for all how to handle it. To me it really seems better to take some time to listen to feedback and then start the colossal task of fixing or redoing metadata for ALL existing DAZ content instead of just implementing another "QWERTY" type of solution that will years later impact whole generations of content users.
I know this was once again a very long text to read through. I hope you found some useful suggestions.
Put the "pose" folder that contains the MATS for an outfit, inside the outfit folder. And do the metadata from there. That way, you are not scroll-scroll-scrolling, or changing to another folder, to find the MATS that go with something. (this is for DS,not poser)
Whoops, all gone.
Whoops, all gone.
Great thread. Here are a few of my thoughts:
7. (and 14) Anatomy vs. Props/Anatomy… do people think of these as props? I tend to think of anatomy e.g. wings as something different from a prop. Attachment, possibly.
9. Brilliant.
10. Environments -- what's the difference between these and props? From a user's point of view? Is a building a Prop or an Environment? This needs to be made clear or eliminate this distinction. #23 - I thought these were Environments? Is the distinction that Scenes have multiple items loaded, including lights and cameras? That still feels like an Environment to me.
11. Agreed on dropping fantasy, etc. subcategories. Those should be themes.
26. I would leave visibility in utilities.
17. Fits -- should these be in poses at all? This confused me terribly when I first started using DS. I don't care if they're implemented as poses or morphs-- doesn't it make more sense to call them .../Presets/Fits?
25 - Shaping vs. poses - visemes and expressions tend to feel like "poses" to most users, not "shapes." Think of a "shape" as something that will be the same for a character in multiple scenes, but a "pose" as being something that will change from scene to scene. How the asset is implemented isn't as important as how the user will want to use it.
27 - Some armor is probably attachments (do they still exist?) or accessories or something-- what about a protective face mask? This is another area that needs clarification.
28 - I see "with shoes" poses as a a pose variation, probably needing to stay with the comparable pose. But I don't think I have many of these products, so I may not be the best to answer this one.
29 - This is a major issue, because newer users are not going to know what they have for plugins, etc. "Quality" indications of some kind would be good. I think I'd prefer some kind of indication on the asset icon, similar to how the icons currently indicate that they are a prop or whatever.
30 - Think like a user. If it's made to go with a specific vehicle, it needs to be found near the vehicle.
31/32 - I found the Inj/Rem thing very confusing when I started. I'd select a figure, double-click Inj, and apparently nothing would happen. On the other hand, if I hadn't done that first, I'd try Apply and again nothing would happen. I have a terrible time teaching people to use these. Whatever is done about these, they need to be more clear somehow about what you do with them. Ideally Apply would automatically Inject the morph with the same name, and REM would only be visible if the selected item had the morph injected. I realize that's a code change, not a metadata standard change, but it needs to be dealt with in a way that makes sense to users.
33 - Probably because the UV maps are sometimes different, but I could certainly live without this. If the mat will only work with a specific figure, it should be configured as such. Otherwise, it's up to me to decide if something looks "masculine" or "feminine" on my figure.
34 - Utilities, isn't it? Or some other kind of supporting asset? You don't click on these, do you?
35 - Lights that change a scene need to be in their own location, and I'd rather it isn't called "Shader," even though that's what they are from a technical perspective. (Cameras are shaders too, after all.) Default/Lights, please. Lights that are just props go in Props. Maybe lights that do both should be categorized in both places?
36 - Magnets need to be their own category, and it should be somehow related or near INJ morphs.
37 - I'd say Materials/Skin. If people don't like that for BEO Ripper, etc., then the whole category should change to Materials/Figures.
38 - I have a Props/Tools category that covers a lot of these items. I also have a Props/Money category, and Props/Stationery (which is probably where I would put paint). Eiderdown would go under Props/Furniture, handkerchief would go in Props/Accessories, Horse Blanket would go in Wardrobe (assuming it conforms to a horse). Plume and pouch would be accessories. Bathwater/Shower spray I put in an Effects/Water category, personally, along with Effects/Fire, Effects/Magic, etc. I guess these could go in a Props subcategory.
39 - Fabricator etc, including my own Quilts & Calicos, Pattern Magic, etc…. Most of the time, they aren't actually shaders, but are presets for the DS Default Shader or HSS, etc. Granted, the word "Preset" isn't any more helpful than "Shader." Couldn't all these go in Materials? Beyond that, I personally like having them sorted by type of surface. Fabricator itself would go under Fabric, as would many of the other Fabricator sets. Gemologica kind of points up the problem with Glass as a subcategory name, I admit. "Transparent" would be more descriptive, but wouldn't cover semi-precious stones very well. Then again, those could go in Stone.
More questions:
What's the difference between Animals and Creatures? Could they both be Creatures? That seems the more inclusive term.
Is a vest worn over a shirt, but under a jacket, "outerwear"?
If we have "Default/Wardrobe/Footwear," why do we also have "Default/Wardrobe/Socks"? Why not Default/Wardrobe/Footwear/Socks?
Do elbow ruffles go on Arms/Upper or Arms/Lower, or do we need "Elbows"? (cf Knees)
Addendum: if something can't be used because something else has to be used first, e.g. shader presets that require the shader to be applied first, Apply morphs that require INJ to be used first, gray out the item until it can be used, and show something about the prerequisite to the user, or automatically apply the prerequisite.
Whoops, all gone.
Whoops, all gone.
cridgit,
Thank you very much for taking your time to read through this.
Hmmm, I'm not completely with you on this one. I agree it could be useful to toggle recursive on/off. Currently, Smart Content is recursive while Content Library is not. Personally I find the recursive view much better. From my perspective, the guideline is you place assets in subcategories when it is clear which subcategory they belong to, but leave them in the parent category when it is not clear. Otherwise you force people into having too many subcategories or the dreaded "Other" subcategory.
I could argue that parent-child folder is a hierarchical relationship and therefore everything within a child or descendant subcategory is related to the current category. Therefore, by definition the recursive view makes sense. I can support having this as an option (a toggle button) but taking away this feature removes a very powerful user experience, IMHO.
I also would under no circumstance want to remove the "recursive" view in all tabs that feature metadata. That contents of folders that are on lower levels are also displayed is what makes browings like that so much more powerful than the folder view in the Content Library.
BUT because of the "recursive" view there are several implications what a smart folder structure is and what not.
Danger number 1 really is that some categories cannot be selected individually anymore when more and more Child levels are added.
We really have to look ahead a few years and imagine how things will look like when we have several 1000s of products installed. The more child levels are added the more difficult it will be to find any assets that are placed on higher levels. Also we have to keep in mind that many of the assets that are placed in the shaping and paramters tab cannot be found in the Content Library. So there is no alternate way to look at them in a normal folder structure. So I guess this problem goes beyond just the metadata team but also concerns all those who set up the categorization for morphs and shapes.
If I would have to set a some rules when making metadata categories they could be:
1) There always has to be a parent category.
2) NEVER put any assets in the parent category
3) All assets go in child categories one level below the parent category.
Again the examples:
Torso/Female/RealWorld (Parent Category)
Torso/Female/RealWorld/Morph Kits (Child Category)
/Animations/By Region/Full Body (Parent Category)
/Animations/By Region/Partial Body (Parent Category)
/Animations/By Region/Partial Body/Arms (Child Category)
/Animations/By Region/Partial Body/Feet (Child Category)
/Animations/By Region/Partial Body/Fins (Child Category)
Now implication of the this folder structre wher you can also see the content of Child Categories when selecting the Parent Category is that each Child Category might also end up being a Parent Category at a later point.
This is what happend in the Torso/Female/RealWorld example.
At first Torso/Female/ was the Parent. Torso/Female/RealWorld was a child. All fine. No Problems so far.
Then at a later point an addon morph product was released. Torso/Female/RealWorld/Morph Kits now became a Child of Torso/Female/RealWorld
The very dire consequence is that now all morphs placed in Torso/Female/RealWorld cannot be dislayed without also displaying all child morphs in Torso/Female/RealWorld/Morph Kits
Now the question seems how could this have been prevented?
Well it could not have been. The problem is allready there from the beginning because of the nature of the level structure that content of all children is displayed as well..
The rules I suggested cannot be followed if later Childs are added below Partents.
The rules may be useful when it is about setting up a categorization for a single product that will not have any addons.
If there are addons it might be useful to add addtional level on the same level as the original child level and not transforming child levels into new parents.
It is allready quite inconvinient now to find the original morphs. Imagine what happens when Morph Kit 2,3,4,5 and so on are released. There soon will be hundred morphs with no option to only display the ones in the parent folder.
I agree with you that it is not an option to remove the Recursive view. But there has to be some kind of toggle system as you suggested implemented as soon as possible.
Thats why I suggested giving some functionality to the Ctrl, Alt and Shift keys when selecting categories in the different tabs.
@ Tags
I do recognize that the Tag system is allready being used. But unfortunately very restrictive.
My suggestions would be that:
All Categories of an an asset are also added as tags.
That way one can also enter multiple categories in the search field to narrow the displayed items down. This is much more faster than actually clicking through the smart content tab and searching around where an item has been placed.
The most important thing to remember is that any folder or level structure is a limitation in itself. Metadata is like a clould of data that should be able to be arranged in many different ways depending on the task at hand.
If Tags and the Categories are the same one can search for combinations of Categories by entering Tags.
Now this way the folder structure is not important anymore and becomes flexible.
Lets have a look at some examples
All female character skins get the tag Materials feminie. All elf ears are asigned the tag elf then in theory I should be able to find all female characters with elf ears.
You can try for yourself if currently that is fully working My search only spit out one product but I do know there are a lot more characters with elf ears I purchased. Let´s be fair I know that the metadata team had their hands full with a lot of things.
Lets look at a current example:
Nautibikini Skirt
It has been assigned exactly one Tag. Nautibikini Skirt.
The most basic functionality is there. Users who are searching for Skirts can also find it. But those who enter the combiniation Swimmwear and Skirt because those are the normaly used categories will not find it.
The category assigned was Wardrobe/Swimmwear/Bottoms
So what I am suggesting to also add the Tags Wardrobe Swimmwear Bottoms Bikini Skirt
The more Tags that fit the better.
At the moment the tags are mostly only the name of the product and the name of the asset.
Again at the moment it may seem rather redundandent to add the categories used also as tags. But as soon as you have 1000 or more products with metadata you will see how incredible powerful the search function then could become. Instead of clicking through the smart content tab users can then just enter the words they are looking for in the search field. And again it will be the combinations that make this more useful than just browsing by categories.
- - -
I hope that cleared up what my intention was. I am sorry I always write so much. English is not my native language so I try to give as many different examples to really bring my point across.
I hope the DAZ team can find a solution to select some Categories in the Tabs with Alt or to toggle on off some switch if the content of Child Categories is also displayed.
If the suggestion to add the Categories as Tags would fall on open ears I would also be happy.
Whoops, all gone.
Rats. I really thought I posted a response to this earlier, but it doesn't seem to have shown up. :(
I think I'd want to move them all into Materials, but it needs careful thought. The differences are:
- A MAT pose or .ds Materials Preset script or MC6 usually applies to a specific object and affects multiple material zones.
- A .ds shader preset or MT5 changes parameters of an existing surface-- if the surface doesn't have those parameters, nothing happens. However, in DS a .ds script usually applies a new shader if needed... but the Poseworks products didn't do that (I think).
- A shader adds new parameters to a surface, e.g. sub-surface scattering. Possibly MT5 files ought to go into this category, because the material room does let you add new parameters to a surface. The Poseworks products are good examples of this. ALSO, just to make things confusing, custom cameras and lights are also "shaders," but they get their own root categories currently. And I think most new users find the word "shaders" completely non-intuitive.
Again, if a script tries to set a surface parameter and can't, because it doesn't exist, it should warn the user, not fail silently. And, just as with INJ scripts, if a shader adds parameters but doesn't actually change anything about how the object renders, applying it should probably show a popup to the user (which can be disabled by more experienced users).
Edited to add: a key point is that Fabricator and other shader presets that can be used on any surface need to be indicated as compatible with ANY object. I don't know how to do that with the current metadata tools.
I would be fine with that. I'd rather have the "imaginary" nature of the critter be dealt with as a theme or tag.
What about toon animals? Robot animals?
Chaps are outerwear on the legs. I think armor would be, too.
Regarding vests, if they have Content Type "shirts," they'll replace a worn shirt if the user has that feature turned on. Are we talking about the same definition of "vest"? I know the British usage includes undershirts, but I'm talking about a "waistcoat." Or outer corsets, for that matter. Things that usually go over a shirt.
But this is my point. Socks are also footwear... and many items are a combination of both, or it's not easy to decide whether they are socks or boots. They may even be called something like "leggins." I ended up combining the two categories after struggling with this for several hundred items.
I've been putting the MFD expansion elbow ruffles on the upper arm, I think... because IIRC, that's where they actually attach. But I could be mistaken. I've never been all that happy with that solution. Next level up is ok, I guess.
Just to keep my eye on this thread. Very interested in this development.