White (maybe uncolored) OBJ in GLSL/C++ - c++

Hi I'm working to create a space environment with a ship inside.But after the creation of the skybox (no errors) I put my ship inside but it hasnt colour. It's something like white-black
I did(modeled) the ship with OPENSCAD and after with MESHLAB I exported it into .OBJ format. I load it inside the source code but he hasn't the texture/colour . That my ship in Meshlab :
I need to know only I have to add something about color in the code or it's error in input. What this?
If you need I post the code, but if is somthing normal this error explain me, anyway I'm a little newbie in opengl, so be patient, thank you
EDIT :
Look my .obj file in windows:
And the same project in ubuntu :
What's this difference?
Anyway the openscad code :
module navicella(){
$fn=100;
rotate([0,180,270]){
union(){
rotate([270,180,0]){
rotate([90,0,0])
cylinder(50,7,10,center=true);
intersection(){
translate([0,-25,0])
sphere(10);
translate([0,-25,0])
cube(19,center=true);
}
difference(){
translate([0,35,0])
cube([10,15,15],center=true);
translate([0,40,0])
sphere(13);
}
translate([5,-10,0])rotate([90,0,70])
cube([35,1,15],center=true);
translate([-2,0,0])rotate([90,0,95])
cube([50,1,10],center=true);
translate([0,3,6])rotate([0,-15,90])
cube([40,1,20],center=true);
translate([0,3,-6])rotate([0,15,90])
cube([40,1,20],center=true);
translate([0,-35,0])rotate([90,0,0])
cylinder(10,5,0,center=true);
translate([0,20,0])rotate([0,90,0])
cube([45,1,2],center=true);
translate([0,25,0]) rotate([90,0,0])
cylinder(5,4,7,center=true);
}
}
}
}
navicella();

Looks like you have forgot to disable all used textures that are not used by your model. That is very common mistake (I do it all the time still today).
What is probably happening?
You rendered skybox or any object with textures
So for example GL_CUBE_MAP and or GL_TEXTURE_2D are enabled. Now when you start rendering your mesh that does not contain texture the textures are still enabled. So for every fragment/pixel GL will always sample the last set texture coordinate from last binded texture in all of the enabled texture targets and combine color according to GL settings.
So if you model does not contain texture coordinates GL will use the last set one. That is usually in corner area where black border is ... or you are just in some dark region of texture. Also if you unbind textures that only means you bind default texture 0 which is usually black.
To test/remedy this just callglDisable(GL_....); for all previously used texture targets. If it helps you know where the problem is.
Also if your object contains texture coordinates and texture is not loaded properly (like wrong file name/path) then the result is usually black.
Missing or negative normals while rendering with lighting enabled
Does not looks like it but it could be also the reason. If your model has wrong or no normals then the lighting computation result in wrong lighting. If the object is always dark even if you rotate it the the normals are negated (facing the other way) and you should change the front face for lighting/material or negate the normals.
If the color intensity is changing with rotation then your object has probably no normal and again the last set normal is used (from previous rendering). In such case either compute normals for the object (via cross product) or disable lighting for that object.

Related

FBX model's faces (some) are not rendering properly

I've created a basic sphere in Maya and loaded it into my OpenGL project. The problem I'm having is shown below:
As you can see, the sphere is triangulated.
But when the model is loaded into my project, some of the faces aren't rendering properly.
These are my Maya FBX export settings (checked):
General Options
- Default file extensions
- Preserve references
Current Preset
- User defined
Geometry
- Smooth Mesh
Convert NURBS surface to:
- Software Render Mesh
- Referenced Containers Content
Embed Media
- Embed Media
Units
- Automatic
Axis Conversion
- Up Axis: Y
UI
- Show Warning Manager
- Generate Log Data
FBX File Format
- Type: Binary
- Version: FBX 2013
Any ideas as to why this is happening? I'm using FBX SDK 2013.
EDIT:
Didn't realize at the time of posting that the white triangles (labeled "bad triangles") appear due to a simple light rendering. But he extended bar on the right is the actual problem.
Saw your question on my youtube video.
It looks to me like some of your triangles are being culled out on the extended bar. Maybe some of the triangles on the bar have incorrect winding? Something to check for. Check the winding on the triangles and play around with the opengl cull face.
as for the shading, I've seen something resembling this before. It looks like you may need to enable smooth shading, instead of flat shading. Try calling glShadeModel(GL_SMOOTH);
Also try calling glDisable(GL_TEXTURE_2D). If a texture is enabled and appropriate texture coordinates are not given, it can result in weird flat shaded triangles like you're seeing.
The only other possibility I can think of is just that your normals are not properly set up. Here are a few reasons this could be happening:
You did not properly export the normals.
You did not properly import the normals into your vertex buffer objects, or however you cache the information
Your shaders (assuming you're not using immediate mode) are not reading or processing then normals correctly.
Hope this helps. Good luck!

OpenGL3 two sets of shaders, texture showing black

I've recently succeeded at making a small test app with a GL_TEXTURE_RECTANGLE. Now I'm trying to integrate it into my larger project, but when I call glBindTexture(GL_TEXTURE_RECTANGLE, _tex_id[0]) inside the render function, it's causing the GL_INVALID_OPERATION​ error. The texture image sometimes shows for a fraction of a second, then turns black and stays black.
I am trying to do this by using two sets of vertex and fragment shaders, one set for the 3D scene, and one set for the 2D overlay, but I've never tried this before so I don't know if that's what's causing the error, or if I should be going about this a different way. The shaders are all compiling and linking fine.
Any insight would be much appreciated, and if it would help to see some code, let me know and I'll post some of it (although I think it may be too much for anyone to reasonably look through).
Edit: gDEBugger breaks at the call to glBindTexture(), and when clicking on the breakpoint, the properties window shows a picture of one of my other textures (one that's being loaded by the 3D scene's shaders), it shows that it's trying to load texture number 1, but I know this number is already being used to draw the same 3D scene's texture shown in the properties window... why would glGenTextures() be giving me overlapping texture id numbers? Is this normal or maybe part of the problem?
The black texture was due to me not forwarding some vertex shader inputs (normals) through to the fragment shader, even though I'm not using normals for anything in the 2D overlay shaders. As soon as I added outputs for all the inputs, and forwarded them along to the fragment shader, the texture was no longer black, but it was still disappearing after a fraction of a second. This was because I was calling glBindTexture(GL_TEXTURE_RECTANGLE, 0) at the end of the render function with the hopes that it would clean up some state... this was clearly the wrong thing to do, because removing that call caused the 2D texture to stay on-screen. Furthermore, calling glBindTexture() with the GL_TEXTURE_RECTANGLE target seems to work during the texture setup stage, but during rendering the GL_TEXTURE_RECTANGLE target was causing the GL_INVALID_OPERATION​ error. Changing the target to GL_TEXTURE_2D only in the render function made the error go away, and everything seems to work nicely now.

Using a .x file mesh with textures is overwriting other objects colours?

Im currently writing a puzzle game in c++ directX 9. Not much of it has been a problem however some of my .x files that I am using (using a mesh class that reads them in etc) seems to overwrite the colours of other stuff.
For example I have a green floor and a white pointer, on a level that has a Diglett looking character that has been made in 3ds and textured then exported to .x using panda plugin, other items that are unrelated start to change colour, the green floor is now a lot darker and the white pointer is brown?
Anyone have any ideas? not sure if its texture overflow or something?
The most likely explanation given the information here is that the mesh is changing some state (such as: shaders, diffuse color render/stage states, etc.) when it is drawn. Then your other geometry is affected by those states. You should make sure that any state your geometry depends on is set to what you want it to be before rendering to avoid it being affected by previously changed state.

Applying a shader to framebuffer object to get fisheye affect

Lets say i have an application ( the details of the application should be irrelevent for solving the problem ). Instead of rendering to the screen, i am somehow able to force the application to render to a framebuffer object instead of rendering to the screen ( messing with glew or intercepting a call in a dll ).
Once the application has rendered its content to the FBO is it possible to apply a shader to the contents of the FB? My knowledge is limited here, so from what i understand at this stage all information about vertices is no longer available and all the necessary tests have been applied, so whats left in the buffer is just pixel data. Is this correct?
If it is possible to apply a shader to the FBO, is is possible to get a fisheye affect? ( like this for example: http://idea.hosting.lv/a/gfx/quakeshots.html )
The technique used in the linke above is to create 6 different viewports and render each viewport to a cubemap face and then apply the texture to a mesh.
Thanks
A framebuffer object encapsulates several other buffers, specifically those that are implicitly indexed by fragment location. So a single framebuffer object may bundle together a colour buffer, a depth buffer, a stencil buffer and a bunch of others. The individual buffers are known as renderbuffers.
You're right — there's no geometry in there. For the purposes of reading back the scene you get only final fragment values, which if you're highjacking an existing app will probably be a 2d pixel image of the frame and some other things that you don't care about.
If your GPU has render-to-texture support (originally an extension circa OpenGL 1.3 but you'd be hard pressed to find a GPU without it nowadays, even in mobile phones) then you can link a texture as a renderbuffer within a framebuffer. So the rendering code is exactly as it would be normally but ends up writing the results to a texture that you can then use as a source for drawing.
Fragment shaders can programmatically decide which location of a texture map to sample in order to create their output. So you can write a fragment shader that applies a fisheye lens, though you're restricted to the field of view rendered in the original texture, obviously. Which would probably be what you'd get in your Quake example if you had just one of the sides of the cube available rather than six.
In summary: the answer is 'yes' to all of your questions. There's a brief introduction to framebuffer objects here.
Look here for some relevant info:
http://www.opengl.org/wiki/Framebuffer_Object
The short, simple explanation is that a FBO is the 3D equivalent of a software frame buffer. You have direct access to individual pixels, instead of having to modify a texture and upload it. You can get shaders to point to an FBO. The link above gives an overview of the procedure.

OpenGL primitives too dark when multitexturing?

I'm having a problem getting accurate primitive colours when I'm using multi-texturing elsewhere in the scene. Basically, I have some lines and polygons that I am trying render over a video texture (I'm using 3 stage multitexturing to create the video texture)... Anyhow, I know the problem is not alpha related... In fact, I know that in my texture update function if I just comment out the calls to glBindTexture() for texture levels 1 and 2, the primitive color is fine (so leaving texture level 0)... Is it trying to multitexture the primitives too (even though I'm obviously not setting texture coordinates for primitives)?
Make sure to disable multitexturing when not using it. OpenGL uses a state machine, so if you turn on a texture it will stay on until you explicitly turn it off.
Just because you're not setting coordinates, doesn't mean OpenGL will assume you're not using the texture.