roland

You can enable "Follow step", for this right click inside the source window somewhere there's no text. This opens the windows options menu.

You can see/edit the LDraw code by opening a source window (View menu). I'll usually dock one at the right (keep ctrl down while moving the new window there) LDCad allows all metas the ones in the bin are just the ones I thought are handy to be able to drag and drop. The fully supported metas have an editing window (press enter when the line is selected). All steps (except the last one) can be turned into rotation steps by editing the current step (ctrl+b). By default the rotations will not be applied while navigating steps, for this you must change the 'NSR" into "ASR" at the top right of the compass.

That's indeed a limitation of the buffer exchange method. As far I know most people usually solve it by using submodels for those collections of parts that need to be readded. Alternative might be the "hide group" functionality of LPub, but that only supports MLCad groups. It will always be visible in the editors/viewers without LPub processing though.

That's because that model mixes part and model content, which is not supported in LDCad due to how rendering optimizations are done. You can use buffer exchange in LDCad by using a source window combined with the special "LDraw meta items" part bin group (icon with the "...." speech bubble), which is located in the "special" group (Icon with many colored crosses). At the bottom of that group there are two items showing a brown box with an arrow point in and out, these are the store and retrieve commands.

You need to look into "Buffer exchange". Mentioned in

Not unless all bricks have the same color, also it seems you disabled lighting which in some cases makes the problem more visible I think. The problem is called 'Z-Fighting' and like Scrubs wrote its in inherit modern graphics card problem/limitation. If you want to make custom bricks without this problem you need to create your own .dat files using an editor like LDPartEditor (http://nilsschmidt1337.github.io/ldparteditor/)

Sidenote: Stud.io files are LDraw, just zipped with some extra stuff. To make decent instructions you need to edit the LDraw files and add instructions on how to generate the pages. Most people use LPub or LPub3D for this.

Did you enable snapping, change GS into PS in the left bottom 'compass' as described here: http://www.melkert.net/LDCad/docs/basicEdit Part snapping is disabled by default because not all LDraw parts have the needed information. I know this can be very confusing when coming from LDD, but in the long run it is worth learning to use the grid editing method as it opens up all >9000 parts.

Is the IGN block really needed as a SUBtitute already implies replacement of the encapsulated parts? Just curious (I' considering adding full LPub support to LDCad 2), also what is the best place for an overview of all the LPub meta's and their syntax?

Yes, you'll probably only have to check the moveLine usage as that function has a big problem in 1.6a (It uses an incorrect index conversion, needed because the internals never really delete lines. Deleted lines are then only hidden for undo purposes so a move is really a del+add opp)

There are still some situations that won't work (e.g. if the current step is the last one and has no items nor a step meta (getStepLineInfo returns 0) Also it seems the wrong line is deleted when deleting the helper line because of the index shift caused by the new lines. I'll make some improvements to the api to handle this kind of scenario much cleaner/shorter. It will be available in 1.6b which I'm hoping to release this month. If anyone has some additional ideas for a practical script please let me know so I can test if it's possible using the current api etc and/or extend it if needed.

You can open multiple source windows if you need to move multiple things from the bottom to elsewhere. Be sure to disable 'follow current step' and 'follow selection' for both windows (right click inside source win). As for scripting, I think you want something like this (not extensively tested though), Add it to "%appdata%/LDCad/scripts/default/global/steps.lua" above the register function function runSelInsStep() --only useful if a model is active. local sf=ldc.subfile() if not sf:isLinked() then ldc.dialog.runMessage('No active model.') return end local ses=ldc.session() local sel=ses:getSelection() if sel:getRefCount()>0 then local curStep=ses:getCurStepNr() local idx=sf:getStepLineInfo(curStep+1) sf:addNewLine(idx, '0 STEP') for i=1,sel:getRefCount() do sf:moveLine(sel:getRef(i), idx) end ses:setCurStepNr(curStep) end end And add macro:register('Move selection to new step') macro:setHint('This will move the selection to a new step after the current one.') macro:setEvent('run', 'runSelInsStep') To its register function Sorry for the lack of (>=1.6) API documentation it is still on my to do list :) edit: This script won't work for the last step, I made a improvement for this but that version won't work in 1.6a due to a bug in moveLine. You can workaround it by adding a empty step to the model. You can remove it again when working with steps other then the last one.

As far I know stud.io pov exports are LDView exports wich most people in this topic use / talk about, so I don't think you need to make a distinction.

imho you should primarily build for yourself, if other people happen to like it too you should consider it a bonus. It is futile to try and please everyone. Just my 2cts from lessons learned while working on my LDraw software and animations.

The log indicates the shadow file is loaded and used, you can see this for example here: 27424 | 2017-11-25_01:18:09 | Progress | render prep | C:\ldraw\parts\4490.dat | Starting 27425 | 2017-11-25_01:18:09 | Info | render prep | C:\ldraw\parts\4490.dat | Raw data has 1272 potential vertices (tri 80; quad 100; norLine 184; conLine 66) 27426 | 2017-11-25_01:18:09 | Info | render prep | C:\ldraw\parts\4490.dat | Mesh reduced to 347 vertices (27.28% of org) 27427 | 2017-11-25_01:18:09 | Progress | render prep | C:\ldraw\parts\4490.dat | Generating normals / smoothing geometry 27428 | 2017-11-25_01:18:09 | Info | render prep | C:\ldraw\parts\4490.dat | Generated 347 normals 27429 | 2017-11-25_01:18:09 | Info | render prep | C:\ldraw\parts\4490.dat | Mesh inflated to 519 vertices (40.80% of org) 27430 | 2017-11-25_01:18:09 | Info | render prep | C:\ldraw\parts\4490.dat | All recursive data has valid BFC information, part will be rendered with culling enabled. 27431 | 2017-11-25_01:18:09 | Info | render prep | C:\ldraw\parts\4490.dat | Subfile has 5 snap info points. 27432 | 2017-11-25_01:18:09 | Progress | render prep | C:\ldraw\parts\4490.dat | Done This is the 1x3 arch brick wich reported 5 snap points (3 on top 2 on bottom). I think this being the first boot after a config reset you probably forgot to enable snapping in the editing session (as it is disabled by default). Change 'GS' into 'PS' inside the compass at the left bottom corner. ps: I think you are using an older library as there are many warnings on some parts I think have been fixed/resolved in later library versions. The shadow is maintained to work best with the latest library.

A couple of things are needed for snapping to work: - Correctly configured shadow libraries (By default one is installed and configured automatically for the official LDraw library). - Use of these shadows must be enabled (prefs/shadow files), is enabled by default but I noticed some people have (accidentally) disabled that option for some reason. - Part snapping must be enabled in the editing session, controlled trough the compass or shift+p - The parts you want to snap must have information in the shadow library which isn't the case for all parts yet as I have 'only' defined snapping info for about half (about 95% of daily use parts though) of the official parts. If with this all checked not even a 2x4 brick will snap, then something else is at play, you could try: Resetting the configuration, by deleting %appdata%/LDCad/config/main.cfg while the program is closed. The program will then reask the ldraw library location at next start and will set all defaults again. If this doesn't work I would need a log file to see if the shadow etc is actually loaded and applied. please mail the contents of (preferentially after open a random model in LDCad first) %appdata%/LDCad/logs ps: There might also be a upgrade bug at play as I had some other people with this problem for whom it at first did work. What version did you install (AIOI, setup, archive, win/linux etc). Hope this helps

It seems the smoothing algorithm trips on something, probably those very narrow triangle shaped rounded edges. I'll have to dive deeper in the part's construction to be able to improve on it. The main problem is LDraw files have no 'normals' so LDCad has to invent them while loading the parts. This depends on certain assumptions and part construction parameters (especially the edges). All LDraw related OpenGL options are found in the prefs/ldraw menu, the generic OpenGL options are in prefs/openGL As of version 1.6 LDCad also has it's own POV-Ray export feature, and if you want extreme HQ you can open the made LDR/MPD model in LDView to export while using the LGEO library.

You could try playing around with ldrawPlasticTrans_f and ldrawPlasticTrans_t e.g. #local ldrawPlasticTrans_f=0.3; #local ldrawPlasticTrans_t=0.7; Seems to work better with black trans, but it reduces (imho) the quality of normal transparent stuff. But you don't have that in your scene anyway.

I'm assuming you're talking about the POV-Ray camera script. Don't forget to add look-at to location when using a non zero look-at.

I just noticed the 'black transparent' on the IR sesnsor of mocbuild101's rendering isn't very realistic. Anyone has some idea on how to improve that, as the LDCad export uses material interior for transparency which clearly doesn't work well with black transparent. Also, @mocbuild101, are you sure you have smoothing enabled (prefs/ldraw/vertex processing), the rendering looks a bit flat shading-y to me. It uses the current 'lookat' so if you center the model on whatever brick ('c') you want to use as the center you should be ok. You can also create your own animation script for (alternative) hardcoded coordinates/distances/angles.

I've released version 1.6a This is mainly a maintenance version addressing bugs, but it also includes a couple of new color bin features, namely: - Direct color selection by number. This is done by typing the number followed by enter while the mouse is over a color name inside any color bin. Or click that text to open a input dialog for typing the number/hex code. - Transparent color indication inside the color bin history bar. As always get the latest version at: http://www.melkert.net/LDCad/download

Yes as it should be 99.95% identical to the current Linux version. I tried to make the Windows version run under wine which it does, but the OpenGL driver in recent mac's seems to miss support for display lists resulting in a broken gui. LDCad 2.0 will no longer use display lists so hopefully it will run seamless using wine then. Someone suggested that, he also suggested using the snap info as rotation points by having the user cycle trough them. I never really figured an efficient way of doing that in the current code/gui though. Again hopefully this will improve in 2.0 In the meantime you can use custom selection centers and or use groups with alternative centers to help posing stuff.

Is that file using spaces or some weird characters in is's filename? That often upsets the older LDraw software tools. Or maybe it uses wrong vertex winding and or wrong BFC tags (I'll have to see that parts source to be sure).

LPub doesn't support multiple libraries, you'll have to merge them all into a single (separate) library and rerun mklist.exe. While merging be sure to copy backwards in order of importance, so (official 1601, unofficial zip, custom parts etc)

I just installed it and it seems to work fine with the 1601 library, I see no reason why it shouldn't as the ldraw library still uses the same format as in 2011/2014. AIOI is just a packaging of a collection of tools for ease of use. You can also install any combination of those tools separately (even recommended for advanced users as many tools have newer versions available then the one in the latest AIOI).