This might sound a dumb question but I am trying to understand the basics of 3d game programming and wanted to know this thing.
I have looked at the samples here https://code.msdn.microsoft.com/Direct3D-Tutorial-Win32-829979ef and I get it how each object's vertices and indexes to those vertices are stored in vertex buffer and index buffer respectively.
What I want to understand is how would I render a scene where I have multiple objects ? How should the vertex and index buffers be set? And how should a draw called be implemented ?
A reference or an example will help please.
To elaborate on Chuck's link, the process by which you will render multiple objects will vary depending on the architecture you choose to use.
Every model is divided into a number sections equal to the number of textures/material combinations it has. Each of these sections consists of a unique texture/material combination and will have its own vertex/index buffer pair.
The reason for this is because the HLSL is primarily designed to operate on a single texture and material at a time. You bind the vertex and index buffers of a single section to the pipeline along with the corresponding texture/material, perform a draw call on it, then bind the buffers/texture/material for the next section until the whole model has been rendered.
The cool part is that you only need to load a model once. As long as you have the information for that model, you can create instances of the model using the same data but different position matricies. This lets you create hundreds or thousands of copies of an object.
My scratch codeed engine handles models like this: during initialization, a model manager class is used to load in all the different models I use and store each unique model into a model class. I then take a pointer to the model class and feed it into scenery managers which give information on what contexts the model appears in. When I populate the game world with scenery, my game tile uses a scenery list class to handle a list of instance structures and render lists. The instance structure holds information such as position/scale/orientation, an AABB, and a pointer to the model class. Each frame, I frustum cull the scenery and populate the render lists with only the instance structures of potentially visible objects and produce an instance buffer for each list to contain the positional information. Then, I can loop through each render list, assign the appropriate buffers and textures, and draw indexed instanced() to render all the copies of the model section.
I'm not sure how my process compares to other engines, but it should serve as a reasonable example of how you might handle multiple objects and then multiple instances of objects. The levels of abstraction I have in my process were chosen due to how my engine works (random world generation). The exact method you use will vary based on your application.
Here is a basic diagram showing a fairly bare-bones set up:
Related
I'm working on an app that will include a set of points drawn from CLLocationManager and draw them on a map. I'll never really have a need for each point as an individual entity, they only have meaning in the context of the path.
Instead of creating a model representing the points, I could just store the path as a big JSON (or other more efficient string format) and thereby read only the single entity when it's time to pull the data out. It seems to me this could save overhead, is that true?
This is something that would need some testing. Finding the path directly which contains the points is probably a faster way then fetching all the points which correspond to a certain path but the part with writing them into strings seems a bit off. Parsing those strings will be slow. (JSON being a string).
For saving the points into paths I would suggest either to also add the point entity which is then linked through reference to the path. An alternative would be to use transformable data; Your point will be represented by 2 or 3 double values which could be put directly into a buffer (NSData for instance). The length of the data saved then defines the number of points as data.length/(sizeof(double)*dimensions). This would be extremely easily done in ObjectiveC while in Swift you may lose some hair when working with raw data and unsafe pointers.
It really depends on what you are implementing but if you plan to have very many paths in the database you can still expect a large delay when fetching the data. You might want to consider creating sectors. Each sector would be represented with the same data as the region (MKCoordinateRegion) where on database initialize you would iterate to create sectors for the whole earth. Then when you are inserting paths you check what regions the path intersects with and assign the path to those regions (many-to-many relation). Now when you show the map you check what regions are visible and fetch only those regions and then extract paths from them.
In the VIPER design pattern, should the Interactor return all the information that might be used by multiple presenter actions or should I have a separate struct for each one?
In my case, I have a map that displays places. To display those places I need to retrieve a list of PlaceItem's from a PlacesInteractor which could have only a coordinate and a color (used to change the pin's head color) that would be transformed into a annotations by the presenter.
Now lets say that when the user selects one of the annotations in the map, a callout bubble should be displayed with more details like the place's name and a circle with the color.
Now I should create a RetrievePlaceCalloutInteractor that would return only the information for one place instead of a list of information for multiple places (Right? Or should I have only one Interactor for both scenarios?).
Should this RetrievePlaceCalloutInteractor return a PlaceCalloutItem with only the name and the color (no coordinate) of the place or should I have a single PlaceItem with coordinate, color and name, that would be returned by the RetrievePlaceCalloutInteractor and by the PlaceInteractor, and would be used by the presenter to construct either a CalloutStruct or a list of MKAnnotations?
Thank you.
VIPER is a pattern, not a very formal pattern, not a religion or a complete app architecture. For me VIPER helped to think more about a cleaner architecture but on the way I had to make decisions that were better for my specific scenario without caring to much about VIPER but about clean architecture. So, from my experience and my point of view the answer to your question is 'depends'.
In my case most of the 'Items' (I call them DO from Display Object or Data Object) have almost a one to one relationship with the 'Entities' (I call them MO from Model Object). Most of the interactors manipulate one type of Entity and they have one MO-DO mapper. I usually use the same DO for different use cases if the interactor handle more than one use case.
BUT
I also have some modules using different DOs for different uses cases, although they relate to the same entity, and also I have some DOs with combine the information of several Entities, let's say for example I needed the user name to add it to 'edited by' of a blog post I use the same DO to combine Post and User Entities.
I think VIPER 'wants' one interactor per module, that kind of forces you to have multiple use cases (related) in it, but it is up to you if you want to use different Items (my DOs) or only one.
Being a purist of clean architecture you should have different interactors, different requests and different responses for each use case.
So, as I started, it depends, the important thing is to 'draw' the boundaries properly and it doesn't matter if it's one or ten Items you use for that.
I want to implement some king of spatial indexing data structure for my MKAnnotations.
Currently it's horribly slow when I try to filter them based on distance criteria ( 3-4k of locations, currently extremely slow with a simple double for ... ).
I'd like to create clusters of MKAnnotations, to decide if it is close to another. Also, these locations are in a somewhat (creation) order and a "previous"/"next" functionality would be needed to "jump" between (this is not a must).
I've read about kd-tree and r-tree structures and they both seem to meet the fast distance/neighbor obtaining option for filtering/clustering, but I'm not sure which is the best for me or if there are other options too.
What algorithm/data structure should I use ?
Update: I store these locations in a Core Data database, they represent a path. When the map is opened they are fetched into an array and then I just use that array for distance calculations and annotation creation.
When the user moves/zooms the map, I loop through them and decide what needs to be changed on map, so it is kinda static the whole stuff. As I understood, if I'd be using a tree, I could store the locations there and when a zoom/move happens I just search through it and obtain the ones in the new region. Is this true ?
Even in the dynamic case, when I can add new locations to this array, it would be a single insertion and it's happening rarely.
It depends a lot on what your usage patterns are (how my writes, for example, in-memory or on-disk) and how your data looks like (that is how it is distributed).
R-trees are good because they are balanced, and allow updating. The R*-tree in my experience is clearly better than the other variants because of the split strategy it has. The benefit is that it produces more square pages than the other strategies, so that for many queries you will need to scan fewer pages.
kd-trees are good if you are in-memory and static. Updating them is very bad, you will need to rebuild the index quite often.
And if your data does not change very often, bulk-loading for the R-tree works very well. You can do Sort-Tile-Recursive bulk loading, which essentially requires (partially) sorting your data on X and Y alternatingly, so it takes a low O(n log n) to build the tree; very similar to bulk-loading an kd-tree, except that you multi-split instead of binary splitting. This is very popular.
Furthermore, you can keep track of the number of objects in each page. When displaying things on a map, you may want to stop early when a page would display too small on the screen (i.e. smaller than a marker). At this point, you would not scan that page, but only take the number of objects and display that as a clustered marker until the user zooms in.
For 2D data, with a limited value domain, do not overlook the simple things. Quadtrees can work really well, too! Simplicity can make it a lot easier to optimize things. Or a classic grid approach. If your users tend to spread their annotations in an area (and not put them all into one place), you can just compute integer x,y grid coordinates, and then hash them and make a list for each grid cell.
I am no iOS developer, but I looked over the docs and found this:
MKMapView.annotationsInMapRect:
Returns the annotation objects located in the specified map rectangle.
(NSSet *)annotationsInMapRect:(MKMapRect)mapRect
Parameters
mapRect: The portion of the map that you want to search for annotations.
Return Value
The set of annotation objects located in mapRect.
Discussion
This method offers a fast way to retrieve the annotation objects in a particular portion of the map. This method is much faster than doing a linear search of the objects in the annotations property yourself.
This suggests that the NKMapView already organizes annotations in a spatial index structure. Would this method meet your needs?
If not, I would look for existing open source implementations of any 2D spatial indexing structure and pick the one with best documentation, cleanest interfaces, etc. rather than worrying about efficiency. If you need to write the code form scratch, I think a quadtree would be the easiest to implement. On the other hand, the Wikipedia article on R-tree seems more specifically targeted towards mapping than the K-D Tree or Quadtree.
Found this Best Practice and it's even got inspection in RubyMine:
"Only one or two instance variables are shared between each controller and view.)"
(Ruby on Rails Code Quality Checklist)
What is the suggested way for example - to pass two arrays and their total values calculated in the controller, which makes 4 instance variables? Or to pass to a Javascript data table the: data, total items, total items displayed?
I think the most sensible way to respect this is to go from many simple objects to few complex objects.
Let's say, for instance, you have three separate variables now:
data array
total data items
total items displayed
Now, instead of using 3 separate instance variables (one Array, two Fixnum), you could create a Hash which holds all three of them, or perhaps define a new class which responds to methods such as total_items that you can call in the view.
In fact, as one example, will_paginate does something like this: A paginated collection of items is not simply represented as an array, but as a WillPaginate::Collection object, which responds to methods such as current_page, total_pages, total_entries, etc. This is more natural than having separate variables, since it more accurately maps the relationship between the information you're interested in sharing with your view.
As a rule of thumb, I would suggest that anything which corresponds to closely related information should always be in one instance variable, but anything that isn't really related at all should not be "forced" into one variable because of these best practices. Every rule has an exception, so if, for example, you really have 5 different components in your view which have absolutely nothing to do with each other (which is rare), blindly following the best practice might not be the best idea.
Bottom line: Understand the idea behind these rules, and you'll know what to do.
I'm looking for a way to parse a text to turn into links the entities of my web app contained within the text. To make it clear, let's take this text as example:
Stoner rock and stoner metal are two related sub-genres of hard rock and heavy metal respectively, both combining elements of psychedelic rock, blues-rock, traditional heavy metal and doom metal. The genre emerged during the early 1990s and was pioneered foremost by the Californian bands Kyuss and Sleep.
I'd like to link all the genres, bands and albums that appear on the text (and exist as entities on my web app), like this:
Stoner rock and stoner metal are two related sub-genres of hard rock and heavy metal respectively, both combining elements of psychedelic rock, blues-rock, traditional heavy metal and doom metal. The genre emerged during the early 1990s and was pioneered foremost by the Californian bands Kyuss and Sleep.
I've thought different alternatives, such as:
Storing rails code in the database which would output the links (Ugly and insecure),
Do a full search on the database before inserting the text and
a. Find and transform all my entities into links before saving or
b. Store the entities ids on a separated column, place anchor tags and then on the view, combine each entity id with its anchor tag
I'm not really happy with any of the alternatives, I think should be a smarter way to handle this. Can you suggest a better approach? I'm using Ruby On Rails 3.
Pseudo-Codes:
Keywords.find_each do |keyword|
text.gsub!(keyword, link_to keyword, some_path_for(keyword))
end
Depending on how many keywords you have, this task may be quite CPU intensive. Consider storing the text to DB first and have a background worker (like Resque or Delayed::Job) process each test.
Show the original (unlinked) text until it has been processed. I would suggest using two different table fields for the unlinked and linked texts.