For the past couple of weeks I've been working on creating a custom Collada exporter for Revit Architecture, based on the example give here. In order to ensure that my output is correct, I'm comparing it to the output generated by the Revit to Lumion Bridge. I've gone though the files a half-dozen times or more and, aside from the way I name my elements, I cannot find any ways in which my export differs from theirs. For some reason, however, theirs imports just fine and mine doesn't. I'm building this for use with Unity, but I've also tried it with 3ds max and Blender, with the same results in each program.
I was hoping someone could point me in the direction of a Collada debug tool, or that someone may be able to look through the two files and see if they can find something I've missed.
Custom Exporter Output: Custom Exporter.dae
Revit to Lumion Bridge Output: Revit to Lumion Bridge.dae
Thanks in advance for any help, this is really giving me a headache >_>
One thing you can try is schema validation. If you run xmllint on your file, it might discover the problem. This only finds errors that violate the schema though, so it won't catch all problems.
Related
Drake noob here.
I tried running the drake_visualizer and geometry_inspector with my own ROS generated URDF that depicts and experimental setup with two UR10s. This throws two errors
PackageMap is not able to resolve certain mesh files of extension *.STL and *.DAE. This has been well catalogued in this link.
And ROS paths of the sort package://blah/blah do not seem to be resolved as well. I know this because the console throws the following error
Couldn't find package 'blah' in the supplied packagepath: PackageMap:
[EMPTY!]
In another stack question, one of the authors of the Drake repo suggested we can transform the .stl files during build time. I tried searching for how you can exactly do this but couldn't find anything. I have the feeling that I am missing something fundamental here. Any help would be appreciated.
Thanks in Advance
Using Russ's comment, what you need to do is the following
parser = Parser(plant)
parser.package_map().PopulateFromFolder("path/to/folder/containing/package.xml")
parser.AddModelFromFile("your.urdf")
There are many ways to populate the package map, as linked in Russ's comment
I was given a file of an iOS app to look at, and there were five file types relating to 3D animation that I'd never encountered before: .sdru, .mol, .mat (I assume its materials), .pvr, and .tanim. Google hasn't told me very much about any of them, and I was wondering if anyone has any knowledge of these file types, or how I can open the files.
I've been trying to load a library into lua file. Sparing the details, as they are not really important, I have tried this many ways.
The final way, and the one I believe to be correct although I still can't get it to work, is to use "package.loadlib". See code:
ed = package.loadlib("Encode_Decode.lua", "luaopen_ed")
print(ed)
But when I run the program I get this error:
Encode_Decode.lua is either not designed to run on Windows or it
contains an error. Try installing the program again using the original
installation media or contact your system administrator or the
software vendor for support.
I know the program runs because I used it internally to test it's encoding and decoding abilities and it worked fine. I'd really prefer not moving the contents of the library over as my main lua file is crowded as it is. I will if I have to though.
Yes it is in the main folder. I've also tried changing the extension of the library file into a .dll, with the same error.
What am I doing wrong?
I apologize in advance if this is a duplicate, I did my best to research this problem as thoroughly as I could. But to be honest it's almost 3 AM and I've been searching for almost an hour.
Stupid beginner mistake, used the wrong syntax.
require("Encode_Decode")
print(dec("bnVs")) --returns "nul"
package.loadlib is used for loading shared libraries; i.e. .dll or .so files. You're passing a .lua file to it, so Windows attempts to load it as a .dll and fails when it can't.
To load Lua source code, you can use dofile. Alternatively, you can use require, which is a bit more complex, but handles loading modules only once and works with both Lua and C modules.
I am starting out getting more hands-on with FPGAs and have chosen Xilinx.
In a small trial project I have the problem that XST complains about the library proc_common_v_3 is not found. The ise prj file contains paths looking like "../../.." and so on and it gets recreated when trying to change the paths.
When looking in the project list and not the file, the library is referenced using "........", which is different.
Is there another way to make sure ISE handles libraries correct?
ISE Version 14.7
Error message when doing XST->Check Syntax
Xst:2927 - .... line 1: Source file ../../../../../../../../../../../../../Xilinx/14.7/ISE_DS/EDK/hw/XilinxProcessorIPLib/pcores/proc_common_v3_00_a/hdl/vhdl/proc_common_pkg.vhd does not exist
NB: Yes I know there is a thread on this issue, but my comment gets deleted. The answer there is using what seems to be known working paths, but as starting out that is not possible. Better to go for Altera perhaps.
Thanks in advance.
-Michael
Okey, this is not a core programming question; it is more of a question regarding cgns (CFD general notational system) API.
I've exported a grid/mesh file from ANSYS Fluent (which was first created in Gambit 2.46), and I wrote a very simple Fortran program to open and close it (doing nothing else). To check the file is not corrupt I plotted it in Tecplot.
So, when I compiled using gfortran with the mentioned cgns and ran the program I got this error (as part of cg_error_exit_f())
ADF_Database_Open:File does not exist or is not a HDF5 file
Here is the program
program cavity
include "/usr/include/cgnslib_f.h"
call cg_open_f("Cavity.cgns",CG_MODE_READ,index_file,ier)
!check for error if so exit
if (ier .ne. CG_OK) then
call cg_error_exit_f()
end if
write(*,*)"I kind of opened the file?"
call cg_close_f(index_file,ier)
stop
end program cavity
I'm able to write both structured and unstructured grids in cgns format, without any problem.
I suspect the cgns library I'm using(version 2.5.5 packaged in Fedora 15 and Scientific linux 6.1) is built to support only HDF5, while the exported grid file is written in ADF format.
Any ideas to circumvent this or perhaps adding ADF? Which by the way is not packaged in both the distributions. Any other grid generator which is compatible with cgns version 2.5.5?
I hope I was clear. Any further info required, I would provide.
There is so much that could've gone wrong in here, and I'm afraid you didn't exactly narrow the problem down.
You said you exported a file from Fluent (what kind of a file is it? Be sure!). cg_error_exit_f() gave you an error listed. I'm assuming you have the source of the mentioned routines? In the program you include a cgnslib_f.h file - what's in it? I'm assumming the program compiled without errors of any kind, making this a file format question, not a fortran question.
Again, verify what kind of file Fluent produced.
When I ran into this situation, I discovered the following tools:
hdf2adf
adf2hdf
They are in the cgns-convert package on Ubuntu and are probably available for your distribution as well.