HI Christian The more I am thinking about this the more I think your trying to track the wrong thing. You should be tracking edge versions no file versions. Edge changes affect a minimum of one edge per block , but also a minimum of two blocks per edge.
Think of a standard 3 x 3 grid . This would be the base project and all blocks would have 2-4 edges marked version 1 (working on the basis that the outside edge isn’t an issue because it doesn’t need to match edges. A1 A2 A3 B1 B2 B3 C1 C2 C3 Lets say we start at Project X Taking the easiest case scenario in project X you make changes to four squares (A1, A2, B1, B2) and changes to A1 and A2 changes the edge between just them. The four squares are tagged as project X i.e. (A1, A2, B1, B2) In this case B1 and B2 have all their edges remain as version 1 A1 has one edge marked as version 1 , and one edge as version 2 A2 has two edges marked as version 1 , and one edge as version 2 So in your next Project Y (changing all 9 squares) you firstly get a choice of wether to use the base set, or the project x set Once you have made that choice you make sure all of your edge versions are matchable. With this you could possibly have a naming convention that goes something like this A1 Would be Block_A1_Project_X_00_02_01_00 (the zeros denote that no edges need to match) A2 Would be Block_A2_Project_X_00_01_01_02 I must say I don’t envy your task of keeping this straight. ;) If you make changes for lets say project x does the fact that the edges in the inside of the Project X actually matter ? Ie if you have to use Project X rather then the base models do you assume that all of the project x squares need to used ? This would give you an island type approach and would cut down on the number of changes you need to track quite a bit. Kind regards Angsu From: Christian Gotzinger <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday 07 January 2014 at 4:16 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: OT: Organizing files that belong together Hi Angus, All versions of a square have the same grid coordinates, yes. We can't generate an entire grid for each project because the amount of data would be through the roof. We have over 200 squares and to date more than 30 projects. Therefore, we only edit those squares that are relevant to a given project. The rest of the squares are then loaded either from our "base squares" or from another project if multiple projects must be displayed. But we never know whether the squares of one project can be mixed and matched with neighboring squares from another project. I know that we will have to make sure that the file information or database is constantly updated, but we would simply make this part of our checklist when wrapping up a project. Let's say we've output five new squares for a new project. We would then ensure that the information for those squares and all neighbors is updated before moving on. You do have a point though, in that if we ever forget about this it'll be bad :-/ The problem is that the scope is ever increasing. So far we've been able to keep track of things manually, but lately it's been getting harder and harder, and we absolutely need a solution soon. On Tue, Jan 7, 2014 at 2:39 PM, Angus Davidson <[email protected]<mailto:[email protected]>> wrote: Hi Christian a few questions then ;) Will the square and its versions always be at the same coordinates on the grid? In the scenario that a square fits multiple projects is it not possible to just have multiple copies of the same file (or can max do standins ? That way you have a grid for each project where you will be sure that the edges match. the problem is once you go past 5 or so iterations the number of variables is going to make it nearly impossible to keep all of the edges matching up. Think of a chess board. If you click and set a project , say X to a square it should be able to tell you which adjoining squares should be loaded. If you right click on the square you can get a list of the various versions which still have matching edges Then you generate a file list and import those into max. I think trying to keep that information on each file just needs one person to forget to update and your screwed. You need to abstract the physical file and the overall grid data. ________________________________ From: Christian Gotzinger [[email protected]<mailto:[email protected]>] Sent: 07 January 2014 02:36 PM To: [email protected]<mailto:[email protected]> Subject: Re: OT: Organizing files that belong together Thank you for the response, Angus. I need to expand a bit on what I wrote already. The files are all MAX files (we use Soft, Maya and Max and store final files in MAX format), but we're looking for an external tool to help us with the organizing. What I'd really like is this: I pick a file, and the tool tells me which projects this file belongs to (some square versions fit multiple projects) and which neighboring squares match at the edges. So I pick file F003_C, and the tool tells me that this is a square of Project X and Project Z, and that fitting neighbor squares are G003_C, G003_D, F004_A, E003_A, F002_A and F002_D We do work off of base squares and edit those, but projects overlap, some square versions are used in multiple projects, so it's rather complicated. For instance, I can't be sure that G003_C fits G004_C. On Tue, Jan 7, 2014 at 12:24 PM, Angus Davidson <[email protected]<mailto:[email protected]>> wrote: My way of thinking of this would be to do it with versioning. Ie for each city square you have a base mesh possibly as emdl to be referenced in. e.g. square_001_base In your first project you will pull those in and place via reference so their edges are correct. Once you have that you can then create different versions of the base squares wether its by naming convention i.e. square_001_x, square_001_y or something like Git / mercurial Then in order to change which squares you pull into the project you can just edit the scntoc file for file bases versioning , or the files will be replaced by the correct ones if you use some form of source control. You could also possibly do it via Level of detail proxies (they will be about the same amount of detail but that’s not really an issue for this) I am sure there is also likely a scripting way to do this easily as well. Kind regards Angus From: Christian Gotzinger <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday 07 January 2014 at 12:56 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: OT: Organizing files that belong together Hi list, We have a digital city model that's divided up into several hundred squares. Our projects require us to make different versions of these squares for planning purposes. So for any given square, we may have 4 or 5 different versions. The more projects we do, the more complicated it gets for us to keep track of what belongs (and what fits) together. When we need to quickly prepare a file that contains "City model with Project X + Project Y", we have two main problems: a) For squares with multiple versions we need to figure out which of these versions are part of Project X and which are Project Y. b) We need to figure out how squares may be combined. Let's say that the square F003_C belongs to Project X, but square G003 is not part of Project X. We now can't be sure which version(s) of G003 properly match(es) F003_C at the seam. I'm unsure how common a problem this is and whether I explained it properly. Does anybody have any pointers as to what may be a good way to tackle this? Maybe some kind of specialized software? Thank you Christian This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. <table width="100%" border="0" cellspacing="0" cellpadding="0" style="width:100%;"> <tr> <td align="left" style="text-align:justify;"><font face="arial,sans-serif" size="1" color="#999999"><span style="font-size:11px;">This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. </span></font></td> </tr> </table>
