Jump to content
  • Advertisement

jffortin

Member
  • Content Count

    195
  • Joined

  • Last visited

Community Reputation

372 Neutral

About jffortin

  • Rank
    Member

Personal Information

  • Role
    Business Development
    Programmer
    Technical Director
  • Interests
    Business
    Programming

Social

  • Twitter
    jffortin3d
  • Github
    jeanfrancoisf
  • Steam
    jff_f
  1. Quote:Original post by saagrawa My project setting are as follows: Additional Incl Dir: "C:\Program Files\Feeling Software\FCollada" Preprocessor Definitions: WIN32;NDEBUG;FCOLLADA_DLL Additional Lib Dir: "C:\Program Files\Feeling Software\FCollada\Output\Release Unicode DLL Win32" Additional Dependencies: FColladaU.dll I don't have access to my code right now... but if I remember correctly FCOLLADA_DLL shouldn't be defined in your code... if I open my project file in notepad I see this as the defines (for debug non-unicode ...): PreprocessorDefinitions="WIN32;_DEBUG;_CRT_SECURE_NO_WARNINGS;NO_LIBXML" I think you would just need to add the "NO_LIBXML" and remove the FCOLLADA_DLL and it should work... I can always have a better look at it later when I get home. JFF
  2. jffortin

    My career plan

    Quote:Original post by Dunge There's two interesting video games studio where I live, so I tried this month to send my resume to the other one. I picked up their interest and they got me for an interview. Two questions: -First, 2 interviews out of two is not bad [smile]. -Second, why aren't you interested in the other studios in the Quebec City area? On the IGDA Quebec City website they list 5 companies. There are usually events that you can assist and meet people in the industry. This can help you. (There is also a chapter in Montreal and people from Media Molecule next week presenting stuff about Little Big Planet). JFF
  3. jffortin

    ID3DXMesh and 3DS

    Quote:Original post by EmptyVoid Are you saying most games use index and vertex buffers? If so then why would that make any since? There are optimizations, mesh simplification, auto generation of adjacency, attribute buffer and other things that would make the mesh classes the smartest option in my opinion... Mesh exporters should be able to optimize the meshes directly at export so you don't have to worry about optimizing the meshes on load (which also gives you longer load times). JFF
  4. jffortin

    Texture and collada

    In FCollada (the only COLLADA API I know) you access the path through the FCDImage class. Which can be accessed through the image library or through the materials (surface parameters). It's all in the documentation! JFF
  5. jffortin

    XNA - The Future

    Quote:Original post by Roger Gerald I recently downloaded XNA and started writing my own programs for the xbox 360. Its been almost 20 years since I was programming in C (even Pascal!) and so obviously a lot of things have changed since then but i found myself being disappointed that things were no easier now than they were back then. Trust me, things are a lot easier than what it was back then. Programming in itself is basically the same but with a different level of abstraction because of APIs that were developed over the years and some newer language features. Back then you didn't have the nice 3D APIs we have now. Things like XNA allows you to work in 3D in a even higher level and forget about most of the hard stuff (like the initialization of the API that has been abstracted). Languages like C# pushes a bit further with features like garbage collection (and others) that can make the life of programmers a lot easier. So libraries and the evolution of languages are what changed a lot on the programming side. Maintenance on big projects is also a lot easier now with the "new" languages (when they have been designed correctly). Quote:Original post by Roger Gerald There were loads of tutorials and videos to help me on my way, but ultimately it was still too complex. I kind of wished for a simpler set up where the application works out all the hard stuff and simply asked questions as to where you wanted to go with the program. If you wanted a game generated for you, programming is probably not your best choice. There are programs that are made to generate games for you (but you are limited by them). Quote:Original post by Roger Gerald I am not a programmer of course, but was just interested in how profesional programmers feel about this : is it possible to simplify these applications? It is always possible to simplify the work required to do something. The only problem is that with each abstraction layer you lose freedom because you limit possibilities offered to you. i.e. You want to make a RTS and you choose an engine made for RTS where you define everything your RTS needs (units, buildings and the associated art) and then it makes the game for you. This works, you have a new game but you can't add anything new, you are just building the same game over and over with new assets. You can't add any features that the engine wasn't designed for... unless you edit the engine's code but you lose the abstraction and go back to the point where everything is not as simple. And don't try to build another type of game with this engine as you will most likely fail since it wasn't designed for this. JFF
  6. jffortin

    COLLADA loader

    Note: I've only used FCollada in real applications so I can only comment on that. First time I made a COLLADA loader using FCollada it took about a week to learn the API and make my first loader. Also since my applications interacts with ColladaMax or ColladaMaya I thought it was logical to use the library that is used to make those plugins. I recently ported my projects to support 64-bit and haven't ran into any problems yet. I actually didn't have to change a thing on the loader to support 64-bit (probably because I was careful to use the correct types all the time). JFF
  7. jffortin

    Compilation errors (FCollada)

    Hi, Never had any similar error... and never had to modify any files to make it work. What version are you trying to compile? The only thing I did was to define "NO_LIBXML" and set the include directories. Just post more information about the environment I can probably provide free support for something like that since they stopped providing it [wink][wink]. Can you tell me what you have done at the moment (defines, include dirs)? Which configuration of FCollada are you compiling? JFF
  8. jffortin

    D3D10 and Input Layouts

    Quote:Original post by darkelf2k5 If you want to preserve space and not keep all the shaders in the memory, keep only the input signatures. The Input layout only needs the VS's anyway. Use D3D10GetInputSignatureBlob(). Well I'll be registering only the signatures that I need for the shaders I'll be rendering with so I guess (if I understand correctly) I won't save anything. I just get the signature from the effect pass descriptor like this: ID3D10EffectPass* pass = technique->GetPassByIndex(_index); pass->GetDesc(&passDescriptor); JFF
  9. jffortin

    D3D10 and Input Layouts

    Quote:Original post by XVincentX From Direct3D 10 FAQ: I need a shader signature in order to create an Input Layout, but I load my meshes and create layouts before creating shaders. What do I do? One solution is to switch the order and load shaders before loading meshes. However, this is much easier said than done. You always can create the Input Layouts on demand when needed by the application. You will have to keep a version of the shader signature around. You should create a hash based off of the shader and buffer layout, and only create the Input Layout if one that matches does not exist already. I guess I somehow forgot about FAQs when looking for solutions... Quote:Original post by ET3D So if, for example, all shaders using a certain vertex structure have the same input structure in your HLSL file, then you can just use a single input layout and keep it with the "vertex declaration" object. My next try after reading the two posts would be to have a std::map or similar in the vertex declaration class I have. This would map shader layouts and input layouts so I could make a quick query to the map to retrieve the information I need when rendering. This solution sounds good and doesn't add a new responsibility to the render device class (which was my main concern with what I was doing). Thanks for the help so far! If anybody still has something to add to this I'm still interested in more ideas. JFF
  10. Hi, I'm currently updating/refactoring some engine code for D3D10 and I can't find a good way to encapsulate the input layouts. It's the fact that they link the vertex declarations and the effect passes in some way that makes it hard. First pass was to make this works. But recreating the input layout object for each passes, each vertex buffers on each frame is really not the best idea. How have you done this? Whose responsibility to manage these structures? Is there any examples that are worth looking at? Objects can share the same input element descriptors (a.k.a vertex declaration in D3D9) but might be rendered with different shaders, which means different passes and might need different input layout objects. Also each passes could be used to render objects using different descriptors so the passes might need to mange more than one input layout object. I was thinking about creating a structure to manage this in the D3D10 render device because it's the only class that will know about all the different objects at the API level. But this doesn't sound like a "clean" solution to me. JFF
  11. jffortin

    Computer Vision

    Quote:Original post by VprMatrix89 I'm interested in learning the techniques of 'computer vision', specifically taking a 2d image and defining geometry from it. Defining geometry is already part of the harder stuff... Also, calculating the distance of objects from one image (unless you meant in pixels) in virtually impossible unless you have lots of information about the objects themselves and/or the environment where they are. Start by implementing some edge detection techniques (like sobel to give you one word you can look at), each techniques have their drawbacks. Try to understand how they work mathematically as this will help you to understand what defines an edge. After that, you could try to make a corner detector (could be useful later in detecting geometries like squares, rectangles, etc). Hough transform is also something useful to learn. If you want to reconstruct 3D geometry you might need a stronger math background and lots of patience. Reconstruction using silhouette of object might be the easiest one to understand and implement if you are new to this (Shape-From-Silhouettes). Quote:Original post by VprMatrix89 Does anyone know a good place to start for this, maybe a link to some code? A good place to start is google, I guess I gave you enough keywords to start. Google has always been my first "reference" when I couldn't find something in my notes or needed more explanation than the teacher gave during his lecture. JFF
  12. jffortin

    Collada Mesh Loading

    I have never been that far with COLLADA DOM API but using FCollada and Direct3D 9 was easy. I would iterate all the different geometry source and create a vertex declaration from that... I guess this would be the same for the vertex layout. Next step was to create the vertex buffer itself... I recreated the data like D3D9 wanted it instead of all buffers separated like it is in COLLADA. In other words, I iterated over all the different geometry source and placed it correctly in a memory buffer that will be sent later to the GPU. I'm sure that this would be the same in D3D10. After those steps you would have your meshes. Next step would be to find the geometry instances related to this mesh so you can load the materials. Sorry that I can't help you with COLLADA DOM... but similar functions should exist. JFF
  13. Well, first I'm not studying in a "pure" CS program, to make it short it is a CS program specialized on the medias (mostly image, sound, video, 3D). And I specialized a bit more in computer vision with optional courses. All the programming related courses require us to use C++... well except one teacher that didn't care and we just had to ask him if he could run code written in the language we wanted to use. In the more "math" courses we used the MATLAB and MAPLE "languages" a lot. JFF
  14. jffortin

    model files

    Quote:Original post by WanMaster Quote:Original post by staticVoid2 thanx, what format is the most well known or best in your opinion? and can I get freeware editors for it, because I've heard that 3ds max costs somthing close to £2000. Blender is free, and can export to many formats. As for the format you want to use, that depends on your requirements. Depends also on your level! If you are a beginner I won't suggest things that are complex. In my case, supporting inter-exchange formats allowed me to support many DCC applications. I had a requirement which "translated" was to make all I can to make it easy for artists to import data in the engine so I ended up supporting data from as many DCC tools I could. And that also meant that I should support the tools artists already know as much as I can specially for things that those tools were designed for like Scene Editing. For example, I made a loader/exporter lib for my renderer that accepts DAE (COLLADA), FBX (Autodesk Proprietary format) and my own format. It can load all three and write only in my own format (so I can export the data). FBX is supported by at least Maya and Max, COLLADA is supported by Maya, Max, XSI and many others. I will also note here that those are formats are just too complex for game development and shouldn't be used directly in games. Haven't looked at the FBX plug-in for XNA yet [wink] and hope they made a better interface for game developers. I'm planning on having my own Scene Editor later that will also allow me to modify bits of models or scenes to add things specific to the engine and create other structures that can't be made in current DCC tools. But for now, and probably for a long time, all my scene editing will be done in DCC tools. One remark I always make when talking about those formats is that those should only be used to communicate between tools and shouldn't be used in the end as the format you load in the game. Parts in bold are there to insist on the fact that this applies to me and not necessarily to you as you should choose with your own requirements (or finally set them if you don't have any). All decisions should depend on your level and requirements. Loading [OBJ, .X, .3ds, etc.] files might be the best if you are beginning in the 3D world and many more advanced people still use them (most don't need more than that). Also, there is a free version (for non-commercial use) of XSI that can export COLLADA, .X, Obj, etc. formats (limited to a maximum of 65 000 polygons, I think). Even though I have a license of XSI 5.1 I don't even use it anymore and use the free "XSI 6 Mod Tool" instead. JFF
  15. jffortin

    Its 2008. Whats the latest with 3D scanners?

    Well... trying to put colors showed a bug! Wasn't doing the rotation correctly... I was using sin() and cos() with an angle in degrees! Didn't expect such a mistake from me! Now the whole thing looks a lot better! I can even distinguish the wings now [wink]. And I remember that the laser wasn't going up to the head of the angel. Can see the wings: Details on the flowers covering the base of the object: A picture of the original thing (the images used for the reconstruction we not taken in the same conditions): Now we can see that this has "correctly" reconstructed except for some scaling (because the calibration data had to be estimated since I accidentally lost it). I hope you can "see" the 3D correctly... showing a point cloud in images is hard. Also hope that the colored passes helps you (I have 6 colors and they loop over the whole 360 view). In the last picture you can also see the way things are setup. Camera mounted at the base of a T. Laser and objects would be on the top line. Laser and camera pointing to the object. Now I need something I can rely on for the object rotation. JFF
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!