slow corridor rebuilding after adding superelevation

[wang890]

why??

was ok previous years.

[xquilax]

I have the same problem and I couldn't find any solution to this issue.

Leonardo.

Civil 3D 2012 SP2.1, Intel Core I7 2400k CPU @ 3.4GHz, 8Ggb Ram

[wang890]

i removed it and it is faster but still not as fast as before i put SE in.

well just have to live with it. it has something to do with their new superelevation editor and probably changed the way it interpolates intermediate station SE when corridor subassembly runs and read that number. i'll look in the coding of subassembly functions maybe can improve a little. right not just keep SE out since it's not too importatn for this "feasiblitiy study" project. my road is 60km per segment you can imaging how slow it is.

i really think 2011 is the best version.

so 2013 is ok can anybody confirm this?

[kiyabole]

wele u knw i think u need to use data shortcut so that civil 3d runs smoother. put SE on ur alignment and creat a data shortcut for ur alignment.

[wang890]

i am not a beginner lol.

why don't you try model something 100km and run the corridor before and after putting the SE in?

it should be slower makes sense because it has to calculate that in the subassemblies. but i am saying it is extremely slow takes minutes to build a corridor. i like how the old superelevation is. worked fine before for highways with spiral even. it's always better to have a table format.

[wang890]

this corridor even after i removed all the superelevation with the remove all button the corridor is still slow.

i will take the files home and try it on 2013 and see if that works and report back my findings.

the untouched alignments with it's corridor still rebuilds fast. we are not talking about slow computers here. there is some extra code the program is running.

now i noticed there is a roadway type selection combobox in the assembly. seriously? maybe that's why.

autodesk you gotta stop adding new features. it's good enough already. just make the program run faster and can handle large projects. we had enough pain on the portmann project already.

probably is the subassemblies runs too slow. why not have some  codes to divide the corridor into multi thread and then we are in business. get one processor to process certain range or something and then just join the featureline and build the corridor surface in the end. that step should be quick.

so for now any more input from anybody? try 100km alignment with 100 curves just circular i am not talking about scs here. and then put 2 shoulder extend all with daylight general on each side. then make a corridor every 50 or 20m and take a look at before putting SE in and after putting SE in. see how slow it becomes.

[wang890]

did some more testing. i have the corridor deleted and made a new one with a assembly without any subassemblies on it. still **** slow.

ok i have posted a sample file. so the nice people please help me test.

i have 2 alignments in side on called segment c and one called segment E. the c i have never touched the superelevation, E is put in superelevation and now all deleted.

i put in 2 corridors. called good and bad.

the assembly doesn't have anything on it. just an assembly. the segment c is 100km and e is 56km. the e takes like 20 times longer to rebuild the corridor than c.

now we get it to this stage it is obviously there is a bug.

maybe someone can program something in .net to delete? i looked at com objects and superelevation editing is not exposed. which i thought it was. must be removed now.

[sboon]

I can confirm this behaviour, and I may have a possible fix.  I tried to get rid of the superelevation data, and anything else in your drawing that might be causing a problem.  Nothing seemed to help, and as soon as I opened the superelevation tablular editor for the "good" alignment that corridor started to have the same slowness - even though I had not added any superelevation data.

Next I tried moving your data to another drawing by exporting it to LandXML and importing to a new, clean file.  I noticed during the import that the "good" alignment included geometry and profile data only, but the "bad" one included a lot of superelevation region data.  I found again that a corridor created from the "good" alignment worked fine but the "bad" alignment was slow.

For the third test I imported the same xml file again, but this time I turned off all of the superelevation data.  This solved the problem - both corridors build very quickly as long as I do not open the superelevation editor.

[wang890]

Thanks steve for testing this.

as i suspected. there are some "leftover" SE data within the alignment not exposed to the user. i think that button did not erase properly that is key. maybe they forgot to commit the transaction something like that in .net api. not sure they use api lol.

i can do this for now but doesn't export to xml and reimport get rid of  the PI intersection on the tangents?

maybe with .net api not com api can delete these hidden surpelevations?

but then again this is super important for most people to have the SE calculated when running corridor. i don't care too much at the moment because the project is a feasibility study. but if goes to detail then i will SE this road for sure.

let's hope 2013 fixes it. i will test tonight for sure. i alread emailed myself this file.

oh i tried on sp2 and no sp for 2012 does the same thing for this.

i swear in 2009 version this was fine before they changed the way superelevation looks and edits. if 2009 has the profile projection i think it would be the best version ever.

all i care is speed. i need my job done fast. there is no time to waste waiting for the computer to react. shouldn't be like this in 2012 with all the powerful computers. poor coding is the killer. alright i think i complained enough. maybe someone is watching this from autodesk and can release a patch like .arx or dll file. private release like that last time they did when i was on a major highway project some file started to infect another file and make it save and open super slow. something to do with pipe arx file, put the one they sent in and fixed the problem.

[wang890]

ok as promised tried it on 2013.

the "bad" one rebuilds instantly when there is nothing on the assembly.

this confirmed that they changed the coding for that case.

also putting on some shoulder assemblies builts fast for the bad one. which again means that the found out the bug and did something to it.

putting superelevation in slowed it down but still reasonable. it's about 10 times faster even though my machine is running at 5.0ghz. but still that's 2-3 times faster than a 2.4ghz xeon dual core. so where is that 5 time comes from?