I think the identification of the shots actually requiring an adjustement before running the calculation is a very good start. Even in a configuration of caves with entrances on both ends, there's always side galeries that don't requires any adjustments since there are no loop. This combined with the improved import process regarding the direct/backsight pairs of shots should reduce the number of shots requiring some adjustement. However, the cave networks are meant to be discovered and the number of shots will only go one way: up. Optimising the number of shots involved in the calculation is necessary but won't stop that trend, and limiting the improvement to this optimisation will only delay the re-occurrence of the main issue (if the optimisation actually drop drastically the number of shots). Unless I misunderstand your suggestion with the 500 limit, it sounds like an improve "status quo". At the moment 500 is the default limit and if we want to run adjustment above that threshold, we can edit this limit in settings. So if I understand your idea correctly, you would replace this by a feature to authorize an unleash adjustment without having to fiddle the limit, right ? It sound like a redesigned version of the existing but it doesn't solve the main issue: adjustment calculation seems to be ran far too many times when it doesn't seems necessary. For example, if I go from Visualisation to Data - no edit to data - and back to Visualization the adjustment calculations seemed to be called... why? there is no changes to the data? As I see it with my lack of programming knowledge and math behind the seen, CRP should run the adjustement calculation after the data are considered ready for adjustement... calculations would be run once on request, and X_adjust / Y_adjust / Z adjust would be stored, saved and locked until a recalculation is actually necessary. When you wait 20 minutes for each calculation, you have time to ask yourself why the calculations are run so many times and if this is actually necessary. I don't mind waiting 20 min for the calculation if required, but I do mind waiting for what seems to be unnecessary recalculation. Maybe I sound like a smart ass and I apologise for that as I only want to improve the software experience.
Did you check in Symbols that the rotation for sinter and bones is ticked on? might be the problem.
Not too sure which additionnal symbol you are refering to. Available symbols are found under C:\CaveRenderPro\
UIS_Symbol_Import.xml (UIS style icons, these can be imported straight into Symbol) Mining_Symbol_Import.xml (2 icons, these can be imported straight into Symbol) Symbole.xml (can be open as a projet... there are in there a couple more symbols to recover here)
@Emil had some intersting suggestions in Zusätzliche Symbole but I'm not sure his symbol file was ever available.
1) OK 2) Great 3) OK 4) I could but I would love not to have to do this as it would make CRP a step closer to Therion and I believe no one want that :) I have 45 caves and 143 surveyor teams in my file, so being able to query the data becomes more a necessity and I would love to be able to ask CRP "who surveyed this cave?" without digging into the xml.
Maybe our PC isn't powerful enough but on my side we're talking 15-20 minutes with about 2500 shots to adjust. So every time the adjustment calculations are called, I have to find something else to do, which is very annoying.
This is our beast: Intel Xeon X3450 @2.67GHz 2.66GHz, RAM : 6Go, NVIDIA GeForce GT710 WEI : 5.1 Is that enough?
As I see it now, with this 20 minutes delay to think about it, there are far too many calls of the adjustment calculations. Unless there are changes to the survey data required for the adjustment calculations, I don't see the need to call the calculations again and again. For example if I edit the "info" field in the data table, where is the need for a recalculation? In my opinion, the call of the adjustment calculations should be controlled and not automated as
Zitat von CaveRenderPro im Beitrag #9 for example when you change the tab from data to visualization
. Editing any of the data used by the adjustment calculation should trigger a warning that adjustment recalculation is required.
As you may have seen with the file I sent you, our master cave network is 15km long, has 4 entrances and stretch in between "Hyder - Belle", being the highest and Hyder - Exurgence" being the lowest, so the survey shots have to be adjusted all along. So I don't think the weight = 1 could be a very efficient the solution here.
Although I find the direct shot/backsight shot merging is a very good feature, I still don't like the fact that original shots and backsight shots are not imported from the data table after merging. Also, I still think having the pairs of original shots available (but disabled) leaves more options : i.e.: quality control, reverting to one of the two shots if to much divergence. Instead of having the merge process on import, I'd rather have control of which pairs are OK to merge. I suggest that on import both direct and backsight shots are imported in the table and that merging process would be done manually by selecting the pairs we are happy with : i.e. selecting the pairs of rows in the table > RMB > Merge. This should calculate a merged shot and add it to the table by inserting a new line. I think the pair of original should be kept in the table and disabled to make the process revertible, and QC still possible. Also, I think a merged shot should have a higher weight than a direct/single shot, so when merging, the weight of the merged shot should be great than 0.
Hi Jochen, Did you had a chance to test the file I sent you and narrow down the actions that make CRP very very slow beyond the calculation of auto-adjustment?
When drawing a layer, the layers/drawings below are greyed out, and this is great, I like the rendering! It would be even greater if we could create a greyed out copy of each drawing/layer as it would save a lot of time when dealing with the general drawing of a cave with several levels on top of each other.
That was a false alarm. You’re right, it does work. I was trying to use the predefined colors right above the paintroller icon and not the one in the color frame. Sorry for the inconvenience.
Would it be possible to make the surveyor number alpha-numerical?
I use the format 1111yyyymmdd as a format with 1111 being the cave number but some day I have several team surveying and would like to have the following format: 1111yyyymmddA when A is the team (A, B, C, etc.)
I have some issue reimporting the data from Excel as the format applied to each column is left to EXCEL willing. For example, I use 12 digits for the surveyors number (cave number (4) + yyymmdd). when I open the data with Excel, then it turns into 100322E+11 format... and CRP does like it when reimporting. Is there a way to define default format for each column, to avoid that kind of issue?
In Plan mode, Profil can be create using RMB>Profil but there is no easy way to remove them. RMB>remove profil would be one option, or at least make available the column ProfilX and ProfilY in Data tab some they can be set back to zero in order to remove them. Another way is to open the data with Excel, then the ProfilX and ProfilY are available.
Could we also get the altitude as a filter option? I use the altitude as a ref and not the relative height/depth. So when it come to filtering data, I only have access to the altitude via RMB>information but not the height/depth and therefore I have to guesstimate all the time. Not the most practical.
It would be nice to be able to save the colors I use with the "fill passage" feature as we can do for patterns and symbols. I would like to be able to save and name the colors for e.g. sand area, mud area, then when needed I would have just to select the paint roller icon and the predefined color settings in the dropdown menu above, without looking for the exact color I normally use for that. At the moment the fill passage feature only come up with the fill passage default color... and I find it annoying to look for the color I need, even if I use the saved colors feature in the palette: it is limited and I can't name them.
Auto-adjustement with load of shots is a long process to run... fair enough. But when auto-adjustment has been run (i.e. calculation), it should make no difference to the software speed, right? However, I find the software very (very) sluggish when auto-adjustement is on, and most loss of performance are not justified/shou in my opinion. - jumping from one tab to another seems to launch the adjustment calculation again and again (not always though). - jumping from Plan to Perspective does the same. - adding a "drawing/layer" takes forever... - opening a file with auto-adjustment on is so long, that it seems to be crashing...
These are few examples of the things that doesn't seems to work optimaly I think there is room from improvement here.
I'll drop you a PM with link to my master file so you can have a look for yourself.
It is fonctionnal but it can be a tad headscratching to set up...
To keep things easy (in my opinion), I consider a cave network as one entity: meaning it doesn't matter from which entrance I started each part of the surveys, they belong to the same network... so why splitting the data between several data tables/cave entrances ?!? So I decide which entrance is going to be the primary entrance and then I build the entire network from that primary entrance > Master data table. Then I create all the "secondary" entrances (with GPS coordinates, altitude) and add in their data table one lonely data row for each secondary entrance.
This gives me something like this:
Cave #1This is the primary entrance 1.0.0 > 1.0.0 ; 0m; 000°; 0° This is the reference point of the primary entrance (GPS/alti of entrance #1) survey shot data survey shot data survey shot data survey shot data ... that's all the cave network data = Master data table
----- Cave #2This is a secondary entrance 2.0.0 > 2.0.0 ; 0m; 000°; 0° This is the reference point of the secondary entrance #2 (GPS/alti of entrance #2) nothing more
----- Cave #3This is another secondary entrance 3.0.0 > 3.0.0 ; 0m; 000°; 0° This is the reference point of the secondary entrance #2 (GPS/alti of entrance #2) nothing more
When this is done, there a couple of data rows per entrances to add in the Master data table:
1.x.x> 2.0.0; 0m; 000°; 0° (1.x.x is the secondary entrance 2 station number in the master data table) 2.0.0 > 2.0.0 ; 0m; 000°; 0°; (RefCave=) 2
1.y.y> 3.0.0; 0m; 000°; 0° (1.y.y is the secondary entrance 3 station number in the master data table) 3.0.0 > 3.0.0 ; 0m; 000°; 0°;(RefCave=) 3
some more improvements to make it smooth. 1 - top row of the dropdown menu: create new topographe which open the surveyors list 2 - when opening the dropdown menu, if the surveyors number is already filled in, then the corresponding surveyors line (number and names) should be visible (i.e. without scrolling down) and highlighted in the dropdown menu 3 - If several lines are selected in the data table, selecting a "surveyors" from the dropdown menu should apply to all selected lines.
Personnaly, I do my cave drawings in CPR and roughly place texts/names... then I export from CRP to SVG format and finalize my documents in Illustrator (if you use several drawings/layers in CRP, they will come as SVG groups which is very practical) . By finalizing my document I mean: I do have some template ready (A4, A3, landscape/portrait) to import my SVG drawing. Title block, chart frame, North arrow are ready. Scale is ready to be scaled... Then I have to do the following. - Scaling the scale - True north rotation as I do my drawing using UTM grid to be able to draw the grid in CRP so for true north chart, I have to rotate the map - Final text placements and text arrows - Title block - Logos. Done, nice and easy :)