WIP: F-14 B/D
-
I believe the answer u will get will be the less they are the better will be.
Same for texture.
If model one mesh and texture one piece connected will result to the lowest draw calls. Thus lower fps drain… Meaning better fps.Sent from TapaTalk
-
I believe the answer u will get will be the less they are the better will be.
Same for texture.
If model one mesh and texture one piece connected will result to the lowest draw calls. Thus lower fps drain… Meaning better fps.Sent from TapaTalk
Alrigh I get t issue with the draw calls but if I have a texture map and on it I have textures for antennas I’ll have them there regardless whether the corresponding face is connected to my object or not.
The models I was referring to are one model and object the questio is do I add the necessary vertices to the model to connect it all (it will result in more tris anyway you cut it) or do leave them unattached?
Apologies for all th typos I’m sitting in the bar in Berlin and can’t edit it all out:)
-
Glad you like it. Once it’s in Falcon I have a nice little video planned that I’ll ‘film’ with a friend online and the soundtrack to that (even though it won’t have anything to do with Top Gun) will make you faint man :D.
Yeah quoting myself ain’t cool but just to give you an impression of what’s to come this is my first ever youtube upload and I edited it myself pay special attention to 3:33:
I plan to overcome that with the F-14 vid….
-
The models I was referring to are one model and object the questio is do I add the necessary vertices to the model to connect it all (it will result in more tris anyway you cut it) or do leave them unattached?
I can’t say specifically for BMS programming. I don’t know much about D3D…but I do have a good bit of OpenGL mesh import & procedural mesh generation experience. Also from opengl 2+ and d3d 9+ they have programmable pipelines, so I assume the pipeline capabilities and requirements are similar. If someone has more relevant experience, please correct me.
Anyways, I think that it will make things slower if you combine those objects in the way you are suggesting. First you’ll have to add more vertexes and tris, as you have foreseen, but it could be even worse: in OGL, the vertex pipeline wants parity between vertexes, texcoords, and vNormals. These little detail pitot tubes will almost certainly need separate texture coordinates than the fuselage, so to get parity the mesh importer would then need to duplicate vertexes you merged and then you still have all the extra tris you added, which effectively un-does your work.
You could still minimize draw calls by combining the objects (select both, then Ctrl+J), but I think trying to make it all nice and “sealed” is a bad idea. The only way I could see it helping is for depth buffering (it could z-thrash slightly on intersection) but at the distances your model will be viewed from it shouldn’t matter at all.
Going to try to illustrate how I typically do it in OpenGL: a cube in blender has 8 vertexes, and 6 faces. If there’s a single square texture to use for each side of the cube, then we’ll need 24 texture coordinates. We need vertex normals for lighting, we want a sharp faceted look, so each side of the cube will have 4 identical normals, but we’ll need 24 vertex normals as well.
So I run my importer and from that blender mesh it generates 6 separate squares (each made of two tris), one for each side of the cube, each with unique texcoords and vnormals. it’s all in a single 24 vertex mesh, so still one draw call.
vertex buffer: 24
texcoord buffer: 24
vnormal buffer: 24
and a triangle element array: with 36 elements. 6 sides x 2 triangles_per_side x 3 vertex_indexes_per_triangle.
and when I draw, I bind the vertex, tc, and vnormal buffers, and then draw using the indexes from the element array, it jumps around lightning fast and draws them all. Even if they aren’t continuous, like the element array were just the top and bottom tris of the cube, it would make no difference.All that being said, and even if my assumptions are correct regarding d3d, there could be ancient remnants in the BMS mesh format from 1997. I think the quake2 mesh exporter would break the mesh up into triangle strips and triangle fans because they could wring more performance out of it back in the days of the fixed pipeline.
-
These little detail pitot tubes will almost certainly need separate texture coordinates than the fuselage, so to get parity the mesh importer would then need to duplicate vertexes you merged and then you still have all the extra tris you added, which effectively un-does your work.
That would NOT be good :). It makes perfect sense and would explain why other models are structured like that, can anyone confirm this?
You could still minimize draw calls by combining the objects (select both, then Ctrl+J), but I think trying to make it all nice and “sealed” is a bad idea.
I’m aware Ctrl+J does move objects to the same layer and I frequently use it. The reason they’re on seperate layers (objects) right now is simply due to the process of building the model and for visual purposes. In the end I’ll compress it all but (as you know) doing that now would mean when I go into edit mode everything would light up which given the complexity of the model would make my life hell.
All that being said, and even if my assumptions are correct regarding d3d, there could be ancient remnants in the BMS mesh format from 1997. I think the quake2 mesh exporter would break the mesh up into triangle strips and triangle fans because they could wring more performance out of it back in the days of the fixed pipeline.
That’s one cool anecdote from the 3D archive!
-
Well Pumpy Wavey Dave I-Hawk I believe are more appropriate to answer better.
What I posted was from posts that WaveyDave and I-Hawk have made in the past in this forum regarding drawcalls textures and models creation and fps impact.
example if your model is 3 parts lets say and have one texture per part it will be at least 3 drawcalls. If it’s one it will be one.
The guys said 2 parts. One the whole model without the license plates part and a separate for the license plates part and transparencies IIRC.even if uvmapping is broken to pieces dictates drawcalls… yeap talk about killer for the 3d modeler.
One of the reasons I bark for tutorials… info is scattered all over the place.
-
example if your model is 3 parts lets say and have one texture per part it will be at least 3 drawcalls. If it’s one it will be one.
The guys said 2 parts. One the whole model without the license plates part and a separate for the license plates part and transparencies IIRC.If I understand correctly then what you said means that literally all objects have to be connected to one another. If taken to the extreme that means my airbrake would actually be attached to the hydraulic actuator at the point of connection and the actuator would need to be connected to the rear fuselage. Thinking about it now…this cannot be correct.
Take a shock absorbing damper for instance, in RL a damper has two separate parts which are physically not connected. The floating piston is only held in place, guided and operated by gas, oil or hydraulic fluid which I don’t have in Blender :D. Get it? That cannot be modeled if the actuator is animated to look functional as in extend and compress. There’s two draw calls right there if I apply your explanation. One draw call for the floating piston and one for the strut.
Besides using my limited understanding of texture mapping and coordinates I cannot but agree with zimluura’s point about parity and resulting duplication of vertices at edge break points (as would be the case for the sensor shown above).
Yeah, we need to learn MOAR.
Before I do anything else this needs to be clarified :D.
PS: Alternatively everything could be connected (which would mean project conclusion around 2019) and the damper animation would be done in-game by extruding the vertices out of the damper strut in real-time while drawing the texture on the extruding piston - that I would like to see :D:D:D
-
You are right moving part also excluded I forgot about those.
So you see you will have like what 20 moving parts? 4 planes in a flight… 84 draw call just for those if IUC.
-
You are right moving part also excluded I forgot about those.
So you see you will have like what 20 moving parts? 4 planes in a flight… 84 draw call just for those if IUC.
On the F-14 it’s more like 40 due to the complex wing design but yeah I see your point. Question is IF we all understand correctly :)…
Let’s just wait and see until someone who knows for sure responds…
-
example if your model is 3 parts lets say and have one texture per part it will be at least 3 drawcalls. If it’s one it will be one.
In case I was unclear, separate textures also (typically) mean additional draw calls in the gl4 stuff I’m familiar with. Thanks Arty for pointing that out! But the multiple textures can be combined into a single big texture with lots of discrete areas for different bits and that should, ehm err, could reduce it to a single call.
-
While awaiting replies from our model/engine gurus I’ve done some more research and this leads me to the following:
Single object/single mesh throughout the model and all related parts is not feasible and would add tons of unnecessary geometry
Single object/multi mesh seems most sensible (especially for moving parts, I repeatedly saw variations of Arty’s comment when it comes to that)
Low-poly version (lower LODs) will have to be single object single mesh for multiple reasons and I’ll model it accordingly
**So the question is how ‘multi mesh’ can it get? Potential issues affecting the answer:
-
number of draw calls < do single object - multi mesh models result in multiple draw calls if all textures are on a single map?
-
graphics problems resulting from overlapping geometry (two faces occupying the same space) such as z-fighting or other problems
Most comments I’ve found more or less said ‘it depends’. My priorities are highest possible performance and optimization with the highest possible level of detail.
Before anyone thinks this will extremely delay the project don’t worry. On a side note I can tell you that this model achieves a level of detail and authenticity in certain areas that surpass most other models available for use in sims (including the one once displayed in this forum) at a polycount that is 50-70% lower ;).**
In any case looking forward to MOAR input. -
-
In case I was unclear, separate textures also (typically) mean additional draw calls in the gl4 stuff I’m familiar with. Thanks Arty for pointing that out! But the multiple textures can be combined into a single big texture with lots of discrete areas for different bits and that should, ehm err, could reduce it to a single call.
FYI this is the standard operating procedure for models in Falcon anyway as of now. Usually you have 3 textures as Arty pointed out and one of them is the single 2048x2048 or 4096x4096 texture including most of the A/C’s textures. Question is as I addressed above if there’s still multiple draw calls with single object/multi mesh models. FYI the old F-14 model (~2004) had 6 1024x1024 textures for the jet alone and three more for engine/burner, pilots/cockpit and specific weapons - obviously not optimized too much but due to the relatively low complexity virtually no impact on performance.
-
Pete,
regarding the drawcalls and regarding modelling (not unwrapping/texturing),
and with your sensor/pitot example…See…
Every change in smoothing groups force a drawcall.Let’s assume your fuselage would need just 1 drawcall,
and your sensor another 1 drawcall.Now if you would add your sensor mesh/object to the fuselage,
(which will result to a single fuselage mesh/object)
then it would add tons of unnecessary geometry as you said.BUT if all those tris would have the same smoothgroup,
this would result in just 1 drawcall, regardless how high the triscount is.The result on the model will not satisfy you, because you’ll get strange
shadowing on the fuelage/sensors - connection edge until you add even
some more geometry there to get a smooth connection.Now in this case we don’t want a smooth connection,
because that sensor is a part which is on top of the fuselage in RL,
means we want a hard edge, right?So you select those tris of the sensor and give them a differently smoothgroup,
which results in the look you want on the model, but you need now 2 drawcalls again.Additionally you’ve added unnecessary geometry for “nothing” so to speak.
Conclusion:
Simply move your sensor ontop of your fuselage as you already did,
better said … move the sensor a little bit into the fuselage,
to avoid a see through insim and you’re fine.I hope you could follow my “3dsmax” language and this answers your Q.
Dave or Robert will please correct me if I’m wrong.
Now Baby, rock on, on this Baby, … Baby!
Cheers,
LS -
Wow, I hadn’t thought about it in those terms but now that you mention it it makes perfect sense. I understand what you’re saying wrt the smoothing groups, that is actually exactly what I would’ve done if I had attached the sensor to the fuselage I would have ‘marked the edges sharp’ which is the Blender way of saying smooth group separation and the resulting two draw calls AND all the geometry would have rendered the whole thing useless as I’d still end up with 2 draw calls.
Thanks for the clarification!!
You just saved me a ton of tris by the way because I can now clean up all the areas of the model that I built with this approach (make it one mesh, add all necessary geometry then split it by separating smoothing groups). Shit man I wanna cry, that would’ve saved me like 300 hours :D.
Haha…on it goes.
-
Ask Wavey Dave and Pumpy… send them a PM as I don’t see them participate…
-
Ask Wavey Dave and Pumpy… send them a PM as I don’t see them participate…
Tranquilo, hombre They will if they feel they need to.
-
My aviation museum closed a few months ago.
random Off Topic neat time lapse video, right around 1:50 it gets to the SR-71 tear down, the F14D is visible in some shots.
last time I drove by the D was still there.
more On Topic Vid series:
Read a paper a week ago saying that to update the cat for NVGs compatibility all they did was add a few filters to things, and then illuminate the whole cockpit with add-on green flood lighting, and just left all the older red & white lighting in place and the aviators just didn’t use it anymore. Can 't seem to find it at the moment though.
[edit] looks like it was Night Vision for the F-14 Tomcat by Mike Rabens , the guy up there ^
-
Been working on the landing gear as the last big hurdle standing :). The nose and main landing gear doors and fuselage parts have been separated from the main fuselage and all parts have been parented accordingly. I’ve added some orientation transformations as to be able to move parts at the correct angle such as main strut lower part ‘sliding’ out of the upper part.
Also in order to finalize hard surface modeling on the gear and the fuselage parts I’m rigging the landing gear simplistically with empties, constraints, parent/child relationships and manipulating object origins as pivot points. This can all be exported to 3DS but of course once there the plugin will have to be used to redo it in detail.
Currently some of my control arms are not tracking to the empties (scissor arms on bottom and main support beams on top) as they should. Still looking for what the problem is but should be resolved soon.
-
Final step initiated…3ds import. For anyone who ever had any doubts…I had them too :D.
But with a little tweaking I was able to import pretty much everything without any loss. Once you get a hold of it it really works like a charm. I’m almost tempted to finish the modeling in 3ds but Blender has been such a faithful companion that I’ll stick to it until nothing else can be done in it.
-
Final step initiated…3ds import. For anyone who ever had any doubts…I had them too :D.
But with a little tweaking I was able to import pretty much everything without any loss. Once you get a hold of it it really works like a charm. I’m almost tempted to finish the modeling in 3ds but Blender has been such a faithful companion that I’ll stick to it until nothing else can be done in it.
https://c7.staticflickr.com/9/8553/29483146814_e91662659d_h.jpg
Once in 3dsmax, as I’m curious about the tri - count there, can you please …
Select all objects with ctrl+A.
Click “Utilities” (the hammer on the right side) -> “More…” -> “Polygon Counter”
In the opening window mark the “Count Triangles”.Now tell me the tris- count of the selected objects, please.
Cheers,
LS