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]>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]] > *Sent:* 07 January 2014 02:36 PM > *To:* [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] > > 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]> >> Reply-To: "[email protected]" < >> [email protected]> >> Date: Tuesday 07 January 2014 at 12:56 PM >> To: "[email protected]" <[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. > >
