|
»
.k3d file type required for materials management.
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
.k3d file type required for materials management.
by Timothy M. Shead
::
Rate this Message:
> It would save a lot of work if I could select a MultiMaterial and save
> it and all it's requirements, connected nodes and bitmaps to a .k3d > file with the extension .k3dm so that it could only ever me merged, > not loaded as a scene. I'd also like to be able to have .k3dm.gz files > that have all the required bitmaps included. The .k3dm files should be > able to hold more than one MultiMaterial and there should be a File > menu item to save all materals to a .k3dm or k3dm.gz file. Setting aside details of file extensions ... In-general, all k3dml files are equal - some just contain more stuff than others. Similarly, there's no distinction between "opening" a document, and "importing" a document - both operations execute the same code, the only difference is that the former happens on a new, empty document. So the foundation is already there, the only thing you need is the ability to save a subset of a document, instead of the whole thing. Cheers, Tim ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: .k3d file type required for materials management.
by Daniel Scott Matthews
::
Rate this Message:
On Mon, Nov 9, 2009 at 12:29 PM, Timothy M. Shead <tshead@...> wrote:
>> It would save a lot of work if I could select a MultiMaterial and save >> it and all it's requirements, connected nodes and bitmaps to a .k3d >> file with the extension .k3dm so that it could only ever me merged, >> not loaded as a scene. I'd also like to be able to have .k3dm.gz files >> that have all the required bitmaps included. The .k3dm files should be >> able to hold more than one MultiMaterial and there should be a File >> menu item to save all materals to a .k3dm or k3dm.gz file. > > Setting aside details of file extensions ... > > In-general, all k3dml files are equal - some just contain more stuff > than others. Similarly, there's no distinction between "opening" a > document, and "importing" a document - both operations execute the same > code, the only difference is that the former happens on a new, empty > document. > > So the foundation is already there, the only thing you need is the > ability to save a subset of a document, instead of the whole thing. > That is what I thought, it is the dependency management that is tricky, and maintaining the property linking. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: .k3d file type required for materials management.
by Timothy M. Shead
::
Rate this Message:
Daniel Scott Matthews wrote:
> On Mon, Nov 9, 2009 at 12:29 PM, Timothy M. Shead <tshead@...> wrote: >>> It would save a lot of work if I could select a MultiMaterial and save >>> it and all it's requirements, connected nodes and bitmaps to a .k3d >>> file with the extension .k3dm so that it could only ever me merged, >>> not loaded as a scene. I'd also like to be able to have .k3dm.gz files >>> that have all the required bitmaps included. The .k3dm files should be >>> able to hold more than one MultiMaterial and there should be a File >>> menu item to save all materals to a .k3dm or k3dm.gz file. >> Setting aside details of file extensions ... >> >> In-general, all k3dml files are equal - some just contain more stuff >> than others. Similarly, there's no distinction between "opening" a >> document, and "importing" a document - both operations execute the same >> code, the only difference is that the former happens on a new, empty >> document. >> >> So the foundation is already there, the only thing you need is the >> ability to save a subset of a document, instead of the whole thing. >> > > That is what I thought, it is the dependency management that is > tricky, and maintaining the property linking. Yep, I don't think there's any alternative to going through the process of developing some use-cases (your materials are perfect here) where we select the appropriate subset of a document to be saved. Cheers, Tim ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
|
|
Re: .k3d file type required for materials management.
by Daniel Scott Matthews
::
Rate this Message:
On Mon, Nov 9, 2009 at 12:49 PM, Timothy M. Shead <tshead@...> wrote:
> Daniel Scott Matthews wrote: >> >> On Mon, Nov 9, 2009 at 12:29 PM, Timothy M. Shead <tshead@...> wrote: >>>> >>>> It would save a lot of work if I could select a MultiMaterial and save >>>> it and all it's requirements, connected nodes and bitmaps to a .k3d >>>> file with the extension .k3dm so that it could only ever me merged, >>>> not loaded as a scene. I'd also like to be able to have .k3dm.gz files >>>> that have all the required bitmaps included. The .k3dm files should be >>>> able to hold more than one MultiMaterial and there should be a File >>>> menu item to save all materals to a .k3dm or k3dm.gz file. >>> >>> Setting aside details of file extensions ... >>> >>> In-general, all k3dml files are equal - some just contain more stuff >>> than others. Similarly, there's no distinction between "opening" a >>> document, and "importing" a document - both operations execute the same >>> code, the only difference is that the former happens on a new, empty >>> document. >>> >>> So the foundation is already there, the only thing you need is the >>> ability to save a subset of a document, instead of the whole thing. >>> >> >> That is what I thought, it is the dependency management that is >> tricky, and maintaining the property linking. > > Yep, I don't think there's any alternative to going through the process of > developing some use-cases (your materials are perfect here) where we select > the appropriate subset of a document to be saved. > Well there is the smart graph walking method, or the user guided method, or a combination of both where the user audits a graph representation of the automatically selected nodes before they are saved to a file. The user based method requires an interactive graph view of some type. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ K3d-development mailing list K3d-development@... https://lists.sourceforge.net/lists/listinfo/k3d-development |
| Free embeddable forum powered by Nabble | Forum Help |
